CURRENT RELEASE: 1.6
Can't tell if you're joking about the point value for Spinys, as I thought it would be just a number. I did another check, and bopping a Spiny from below gets you 100 points (like you have), but it doesn't actually kill the Spiny in SMB, just makes it hop up. If you were serious about the point value requiring too much change, I'd guess it's because the point values are different depending on the method. Bottom line: bops shouldn't kill Spinys.
As for standing on the edge of blocks, in SMB it looks like you need 4 pixels as Super Mario, and 2 as small Mario. You appear to have this set to 0 as small Mario and 2 as Super Mario. In Mari0, you can have zero foot pixels on a block but still stand on it, probably because your gun extends one pixel further, so your hitbox is still on the block. Anyway, I think you should shift it two pixels in all cases.
Another issue I noticed is some weird behavior with up-elevators when they get close to the top of the screen. Sometimes Mario starts twitching, sometimes jumping is momentarily disabled, sometimes he gets briefly stuck in the walking frame. If you ride the up-elevator through the top of the screen, Mario sometimes falls through the next elevator, landing on the second one down. You can test this at the end of 1-2 by standing nearly on the right edge of the last elevator and just watching Mario's behavior. Also try tapping left and right when he nears the top. This bug can make the elevators in 2-4 a bit frustrating.
Oh, and I realized that your coin-block code is actually completely different from SMB. In Mari0, you always get exactly 7 coins out of a block. In SMB, you can get as many coins as you can, with the block on a timer. The timer starts when you hit the block for the first time; whenever you hit it after, if more than 10 game-seconds have passed, then the block is done after that coin. There is a slight "refractory period" on coin blocks so you can't get absurd values if the block is directly above your head. To see what I mean, use the coin block toward the end of 5-2 in SMB as small Mario, jumping as fast as you can (turbo controller?). Not all of your jumps will yield a coin.
Then again, if you claim to be too lazy to change the number of coins in the block, I'd guess entirely rewriting how the blocks work is definitely out of the question.
As for standing on the edge of blocks, in SMB it looks like you need 4 pixels as Super Mario, and 2 as small Mario. You appear to have this set to 0 as small Mario and 2 as Super Mario. In Mari0, you can have zero foot pixels on a block but still stand on it, probably because your gun extends one pixel further, so your hitbox is still on the block. Anyway, I think you should shift it two pixels in all cases.
Another issue I noticed is some weird behavior with up-elevators when they get close to the top of the screen. Sometimes Mario starts twitching, sometimes jumping is momentarily disabled, sometimes he gets briefly stuck in the walking frame. If you ride the up-elevator through the top of the screen, Mario sometimes falls through the next elevator, landing on the second one down. You can test this at the end of 1-2 by standing nearly on the right edge of the last elevator and just watching Mario's behavior. Also try tapping left and right when he nears the top. This bug can make the elevators in 2-4 a bit frustrating.
Oh, and I realized that your coin-block code is actually completely different from SMB. In Mari0, you always get exactly 7 coins out of a block. In SMB, you can get as many coins as you can, with the block on a timer. The timer starts when you hit the block for the first time; whenever you hit it after, if more than 10 game-seconds have passed, then the block is done after that coin. There is a slight "refractory period" on coin blocks so you can't get absurd values if the block is directly above your head. To see what I mean, use the coin block toward the end of 5-2 in SMB as small Mario, jumping as fast as you can (turbo controller?). Not all of your jumps will yield a coin.
Then again, if you claim to be too lazy to change the number of coins in the block, I'd guess entirely rewriting how the blocks work is definitely out of the question.
Hexonxonx wrote:Can't tell if you're joking about the point value for Spinys, as I thought it would be just a number. I did another check, and bopping a Spiny from below gets you 100 points (like you have), but it doesn't actually kill the Spiny in SMB, just makes it hop up. If you were serious about the point value requiring too much change, I'd guess it's because the point values are different depending on the method. Bottom line: bops shouldn't kill Spinys.
It's because spikeys are goombas. They just use a different sprite and aren't stompable.
As for standing on the edge of blocks, in SMB it looks like you need 4 pixels as Super Mario, and 2 as small Mario. You appear to have this set to 0 as small Mario and 2 as Super Mario. In Mari0, you can have zero foot pixels on a block but still stand on it, probably because your gun extends one pixel further, so your hitbox is still on the block. Anyway, I think you should shift it two pixels in all cases.
That's because getting out of an infinite fall was too much of a hassle with that feature, so I took it out.
Another issue I noticed is some weird behavior with up-elevators when they get close to the top of the screen. Sometimes Mario starts twitching, sometimes jumping is momentarily disabled, sometimes he gets briefly stuck in the walking frame. If you ride the up-elevator through the top of the screen, Mario sometimes falls through the next elevator, landing on the second one down. You can test this at the end of 1-2 by standing nearly on the right edge of the last elevator and just watching Mario's behavior. Also try tapping left and right when he nears the top. This bug can make the elevators in 2-4 a bit frustrating.
Eh. I hate platforms, they were always a pain. I'll take a look at it tomorrow.
Oh, and I realized that your coin-block code is actually completely different from SMB. In Mari0, you always get exactly 7 coins out of a block. In SMB, you can get as many coins as you can, with the block on a timer. The timer starts when you hit the block for the first time; whenever you hit it after, if more than 10 game-seconds have passed, then the block is done after that coin. There is a slight "refractory period" on coin blocks so you can't get absurd values if the block is directly above your head. To see what I mean, use the coin block toward the end of 5-2 in SMB as small Mario, jumping as fast as you can (turbo controller?). Not all of your jumps will yield a coin.
Then again, if you claim to be too lazy to change the number of coins in the block, I'd guess entirely rewriting how the blocks work is definitely out of the question.
I'm not too lazy to change the number, I already knew it's time dependent.
-
simmons2714
- Posts: 22
- Joined: 04 Mar 2012, 21:47
I found this glitch where you can't push the cube thru portals.
http://www.mediafire.com/?qe238wob9e7l3hy
http://www.mediafire.com/?qe238wob9e7l3hy
As there was no space for the box to come out of the portal it jumped some blocks to the left. I guess it shouldn't even go through the portal if it cant come out.
http://youtu.be/oaGW89LC_RI
-
TiagoTiago
- Posts: 101
- Joined: 05 Mar 2012, 07:44
since new versions are coming so frequently, would it be possible to add a builtin updater?
-
EntranceJew
- Posts: 93
- Joined: 05 Mar 2012, 05:37
When using the level editor, when you test a level in a sub-level and use escape to stop testing or if you die mario reappears in sub-level zero regardless of which sub-level was being tested.
-
WanderingTedium
- Posts: 40
- Joined: 05 Mar 2012, 13:54
To everybody posting Bloopers swimming in air as a "bug":
Bloopers are programmed to swim anywhere regardless of the presence of water, even in the original game. Proof of this is in SMB: Lost Levels, which runs on the same engine as SMB and features--you guessed it--airborne Bloopers.
Hell, Bloopers even fly in air in New Super Mario Bros. Wii when placed out of water in an editor. Nintendo just never bothered because Bloopers are water-exclusive enemies.
Bloopers are programmed to swim anywhere regardless of the presence of water, even in the original game. Proof of this is in SMB: Lost Levels, which runs on the same engine as SMB and features--you guessed it--airborne Bloopers.
Hell, Bloopers even fly in air in New Super Mario Bros. Wii when placed out of water in an editor. Nintendo just never bothered because Bloopers are water-exclusive enemies.
No to both.Mariboy wrote:Maurice: Tip for next version. Crouch walking. more selectable maps
Who caresEntranceJew wrote:When using the level editor, when you test a level in a sub-level and use escape to stop testing or if you die mario reappears in sub-level zero regardless of which sub-level was being tested.
Re: Spiny/Spikey scoring problem due to them being Goombas... I think you only need to change two lines in the code. In fireball:hitstuff(a,b) and mario:starcollide(a, b), change the "if not bowser" line to:
if a ~= "bowser" and b.t ~= "spikey" and b.t ~= "spikeyfall" then
addpoints(firepoints[a], self.x, self.y)
elseif b.t == "spikey" or b.t == "spikeyfall" then
addpoints(200, self.x, self.y)
end
Likewise, the bumping from below issue, you just need to change a couple lines in mario:hitblock(x,y,t). In the section "kill enemies on top", just change the code for killing the enemy:
if w.shotted then
if w.t ~= "spikey" then
w:shotted(dir)
end
addpoints(100, w.x+w.width/2, w.y)
end
When you define jumpitems in game.lua, just add goomba to the list. Add the jump code to goomba.lua just as it is for mushrooms, with a check to make sure it's a spikey:
function goomba:jump(x)
if self.t == "spikey" then
self.falling = true
self.speedy = -mushroomjumpforce
if self.x+self.width/2 < x-0.5 then
self.speedx = -mushroomspeed
elseif self.x+self.width/2 > x-0.5 then
self.speedx = mushroomspeed
end
end
end
EDIT: Now tested and code typo corrected.
EDIT2: Another issue that people have noted is that enemies always pop off to the right when fireballed, regardless of which direction they were hit from. Simple code fix: Instead of b:shotted("right") in fireball:hitstuff, do this instead:
self.killdir = "right"
if self.speedx < 0 then
self.killdir = "left"
end
b:shotted(self.killdir)
You can do the same thing in mario:starcollide, but instead of checking the polarity of self.speedx, check (self.x - b.x):
local killdir = "right"
if (self.x - b.x) > 0 then
killdir = "left"
end
b:shotted(killdir)
if a ~= "bowser" and b.t ~= "spikey" and b.t ~= "spikeyfall" then
addpoints(firepoints[a], self.x, self.y)
elseif b.t == "spikey" or b.t == "spikeyfall" then
addpoints(200, self.x, self.y)
end
Likewise, the bumping from below issue, you just need to change a couple lines in mario:hitblock(x,y,t). In the section "kill enemies on top", just change the code for killing the enemy:
if w.shotted then
if w.t ~= "spikey" then
w:shotted(dir)
end
addpoints(100, w.x+w.width/2, w.y)
end
When you define jumpitems in game.lua, just add goomba to the list. Add the jump code to goomba.lua just as it is for mushrooms, with a check to make sure it's a spikey:
function goomba:jump(x)
if self.t == "spikey" then
self.falling = true
self.speedy = -mushroomjumpforce
if self.x+self.width/2 < x-0.5 then
self.speedx = -mushroomspeed
elseif self.x+self.width/2 > x-0.5 then
self.speedx = mushroomspeed
end
end
end
EDIT: Now tested and code typo corrected.
EDIT2: Another issue that people have noted is that enemies always pop off to the right when fireballed, regardless of which direction they were hit from. Simple code fix: Instead of b:shotted("right") in fireball:hitstuff, do this instead:
self.killdir = "right"
if self.speedx < 0 then
self.killdir = "left"
end
b:shotted(self.killdir)
You can do the same thing in mario:starcollide, but instead of checking the polarity of self.speedx, check (self.x - b.x):
local killdir = "right"
if (self.x - b.x) > 0 then
killdir = "left"
end
b:shotted(killdir)
Last edited by Hexonxonx on 09 Mar 2012, 02:59, edited 2 times in total.
I'm having a sound glitch on all my systems (Mac+PC) with a number of speakers greater than 2. My laptop (4 speakers) and my set-top box (5.1 surround) both frequently encounter a bug where Mari0 will only play sound through speaker #1 (leftmost output). This also happens with my USB headphones (simulated surround), and only seems to correct itself once I unplug the sound system while the game is running, close the game, and re-open it. If I sleep my system or power it down after that, however, the bug returns.
It doesn't affect basic mono or stereo setups. Only systems with at least 3 speakers, even simulated.
It doesn't affect basic mono or stereo setups. Only systems with at least 3 speakers, even simulated.
Umm, if you crouch and launch fireballs your hat goes insane
Last edited by RWLabs on 09 Mar 2012, 06:18, edited 2 times in total.
-
TheSandwichAuthority
- Posts: 1
- Joined: 09 Mar 2012, 02:58
Not sure if this has been reported or not yet, but if there's a portal on top or on the bottom of a thin platform, you can't shoot a portal on the other side of that platform directly above/below the portal.
-
TiagoTiago
- Posts: 101
- Joined: 05 Mar 2012, 07:44
Even if you're big Mario?Hexonxonx wrote:You shouldn't be able to crouch and shoot fireballs. At least, you can't in SMB.
For clarity: In SMB, if you crouch as Fiery Mario you cannot shoot fireballs. The B button does nothing.
EDIT: More code fixes, this time for fireballs. In mario:fire(), fireballs are always created with the xposition of self.x+.5, but it should depend on the direction Mario is facing. You can see the problem by getting the flower in 1-1, then standing on the block it was in and shooting to the left and the right. When shooting right, the fireball lands just onto the 6th block to the right. When shooting left, it lands just onto the 5th block to the left, because it was created a full block further right than it should have been. The fix, near the top of mario:fire():
local dir = "right"
local dirpol = 1
if self.pointingangle > 0 then
dir = "left"
dirpol = -1
end
table.insert(objects["fireball"], fireball:new(self.x+dirpol*.5, self.y, dir, self))
The other fix is to make the path of fireballs match SMB. Earlier you said that you didn't want to change this, as it involves game physics, but it only requires three line changes. In fireball:init, set self.speedy = fireballspeed*0.8 rather than to 0. Also set self.gravity = 0. Then in fireball:floorcollide, add the line self.gravity = mariogravity. That's it, and the fireball path looks much closer to SMB.
EDIT: More code fixes, this time for fireballs. In mario:fire(), fireballs are always created with the xposition of self.x+.5, but it should depend on the direction Mario is facing. You can see the problem by getting the flower in 1-1, then standing on the block it was in and shooting to the left and the right. When shooting right, the fireball lands just onto the 6th block to the right. When shooting left, it lands just onto the 5th block to the left, because it was created a full block further right than it should have been. The fix, near the top of mario:fire():
local dir = "right"
local dirpol = 1
if self.pointingangle > 0 then
dir = "left"
dirpol = -1
end
table.insert(objects["fireball"], fireball:new(self.x+dirpol*.5, self.y, dir, self))
The other fix is to make the path of fireballs match SMB. Earlier you said that you didn't want to change this, as it involves game physics, but it only requires three line changes. In fireball:init, set self.speedy = fireballspeed*0.8 rather than to 0. Also set self.gravity = 0. Then in fireball:floorcollide, add the line self.gravity = mariogravity. That's it, and the fireball path looks much closer to SMB.
Hammerbrother bug:
If you make two portals over a hammerbrother, so he can jump into one, he will instead of normal falling through the second and land on the bottom fall through the bottom!
Like this:
_ ... _
..... | Hammerbrother jumps up into 1st portal
..... H
-------- (bottom)
_ ... _
|
V
-------- Hammerbrother falls through bottom when leaving second portal
H
Can't make pictures because I finished the level and don't have time to get there again, happend in 5-2
Moonwalk bug:
Also I tried this:
And it doesn't work in Mari0, Mario just slides to the right without moonwalking.
If you make two portals over a hammerbrother, so he can jump into one, he will instead of normal falling through the second and land on the bottom fall through the bottom!
Like this:
_ ... _
..... | Hammerbrother jumps up into 1st portal
..... H
-------- (bottom)
_ ... _
|
V
-------- Hammerbrother falls through bottom when leaving second portal
H
Can't make pictures because I finished the level and don't have time to get there again, happend in 5-2
Moonwalk bug:
Also I tried this:
And it doesn't work in Mari0, Mario just slides to the right without moonwalking.
-
WanderingTedium
- Posts: 40
- Joined: 05 Mar 2012, 13:54
That's because normally after it jumps it would have to pass through some solid blocks once in order to change floors as they're programmed to do. Since you made it go through a portal first, it's still in the "I-gotta-pass-through-some-blocks-first" phase, which is why it fell through the floor.Psyblader wrote:Hammerbrother bug:
If you make two portals over a hammerbrother, so he can jump into one, he will instead of normal falling through the second and land on the bottom fall through the bottom!
Try crouching, then start swimming. The graphic shows you swimming as if standing, but you're... I'm not phrasing this well am I?
1. Try crouching underwater.
2. While crouching, press the jump button to start swimming.
3. Go to the ceiling
4. Your head is in the wall.
And that's how I got there (an asshole fish decided it'll be funny to hit me before I took a screenie, which explains why I'm small [insert "that's what she said joke" here])
1. Try crouching underwater.
2. While crouching, press the jump button to start swimming.
3. Go to the ceiling
4. Your head is in the wall.
And that's how I got there (an asshole fish decided it'll be funny to hit me before I took a screenie, which explains why I'm small [insert "that's what she said joke" here])
A question - is it a real necessity that before game loads the menu it shows some phrases? Nobody likes to wait... Plus, it's really annoying.
And a bug reports.
First - is that a bug that they are alive at first, while they should've been knocked down by turtle?
The same thing can happen even if you're not using portals.
Is it works with script, that makes them exist and move only when player reach the spot? How about you make this - they will stood still at the place they should appear, but they can be killed by turtle/bullet, and they shall move only when player will reach them?
Second - definitely a bug. If you're being killed or game is just starting after menu, and while you see black screen you're pressing Alt+Tab/switching to another window, game doesn't pauses like it should've. Game simply starts while you're at another program. Unconvenient, if you're playing and pretending to be working at the same time, cuz if there is some enemies at the start of the level or - bam!=) Or even if there is no enemies, the timer can kill u.
One more thing. Have u considered making the ability to shoot portals while holding the box? I know it's probably better how it is, cuz it's the same as in Portal, but still, just asking.
And a bug reports.
First - is that a bug that they are alive at first, while they should've been knocked down by turtle?
The same thing can happen even if you're not using portals.
Is it works with script, that makes them exist and move only when player reach the spot? How about you make this - they will stood still at the place they should appear, but they can be killed by turtle/bullet, and they shall move only when player will reach them?
Second - definitely a bug. If you're being killed or game is just starting after menu, and while you see black screen you're pressing Alt+Tab/switching to another window, game doesn't pauses like it should've. Game simply starts while you're at another program. Unconvenient, if you're playing and pretending to be working at the same time, cuz if there is some enemies at the start of the level or - bam!=) Or even if there is no enemies, the timer can kill u.
One more thing. Have u considered making the ability to shoot portals while holding the box? I know it's probably better how it is, cuz it's the same as in Portal, but still, just asking.
Last edited by get8p on 09 Mar 2012, 08:34, edited 2 times in total.
I personally like them, how is it annoying?get8p wrote:A question - is it a real necessity that before game loads the menu it shows some phrases? Nobody likes to wait... Plus, it's really annoying.
Although I don't know shit about programming, I can assume spawning them when they're not on your screen will lag the game.get8p wrote:First - is that a bug that they are alive at first, while they should've been knocked down by turtle?
[Your image]
The same thing can happen even if you're not using portals.
Is it works with script, that makes them exist and move only when player reach the spot? How about you make this - they will stood still at the place they should appear, but they can be killed by turtle/bullet, and they shall move only when player will reach them?
-
DiamondPhoenix
- Posts: 107
- Joined: 04 Mar 2012, 05:35
...
Sometimes, i wonder if people that register here even played SMB (and Portal) at least once before posting these things... (get8p's post)
Sometimes, i wonder if people that register here even played SMB (and Portal) at least once before posting these things... (get8p's post)
The phrases were added in 1.3 to replace a blank white screen. When they're shown, the game is loading. It takes about 2 seconds, so you must be incredibly impatient. As for the shell bug above, it's not a bug. That's the way SMB works. Go test 5-1 or 8-1 or 3-2 on the original game. You can get some of the enemies to be killed on the rebound. Ironically, your gif does contain a bug: the shell dies when it hits the Koopa Paratroopa at the end.
-
TiagoTiago
- Posts: 101
- Joined: 05 Mar 2012, 07:44
Perhaps entities that can affect other entities could also "awake" entities based on their proximity kinda like how it happens with the player itself but in a smaller range? This way you don't have to keep the whole level loaded but would still be able to make things that go offscreen interact with things that hasn't showed yet in an intuitive manner. Do you foresee any potential issues with this, besides the rare cases where a chain reaction would wake the whole level?RWLabs wrote:I personally like them, how is it annoying?get8p wrote:A question - is it a real necessity that before game loads the menu it shows some phrases? Nobody likes to wait... Plus, it's really annoying.
Although I don't know shit about programming, I can assume spawning them when they're not on your screen will lag the game.get8p wrote:First - is that a bug that they are alive at first, while they should've been knocked down by turtle?
[Your image]
The same thing can happen even if you're not using portals.
Is it works with script, that makes them exist and move only when player reach the spot? How about you make this - they will stood still at the place they should appear, but they can be killed by turtle/bullet, and they shall move only when player will reach them?
That sounds like a medium between loading the whole thing and loading on sight, good idea ;)TiagoTiago wrote:Perhaps entities that can affect other entities could also "awake" entities based on their proximity kinda like how it happens with the player itself but in a smaller range? This way you don't have to keep the whole level loaded but would still be able to make things that go offscreen interact with things that hasn't showed yet in an intuitive manner. Do you foresee any potential issues with this, besides the rare cases where a chain reaction would wake the whole level?
-
WanderingTedium
- Posts: 40
- Joined: 05 Mar 2012, 13:54
A small suggestion, if it interests you:
A shortcut to the menu screen in editor mode through the mouse, like the middle click or something (since all it currently does is reset it to the tile eraser). That way, one could create levels mostly with just the mouse without having to go back and hit Esc.
A shortcut to the menu screen in editor mode through the mouse, like the middle click or something (since all it currently does is reset it to the tile eraser). That way, one could create levels mostly with just the mouse without having to go back and hit Esc.
Not a bug. Kills do not register when the enemies are offscreen. Same deal in the original.get8p wrote: First - is that a bug that they are alive at first, while they should've been knocked down by turtle?
I reported this when it was 1.2 and it has not been fixed. Apparently, it doesn't occur often enough to warrant a fix.azyclar wrote: At the end of 5-1 I died while on the flag pole, when a bullet bill hit me. No screenshot, sorry.
I played SMB (and Portal), and I know it wasn't in original game. So what? It looks extremely stupid, when u sending them a shell and they only got killed when it's rolling back.DiamondPhoenix wrote:Sometimes, i wonder if people that register here even played SMB (and Portal) at least once before posting these things... (get8p's post)
Ps.TheSandwichAuthority, you're totally right. Though it took me a while to understand what u have ment. Turns out, you cant make another portal under/below the first one at this thin platform, here
I can somewhat confirm that kicking a shell into a walking koopa will kill both the kicked shell and the walking koopa. The kicked shell should pass through the walking koopa and continue on its destructive path. Only when 2 kicked shells collide, a kicked shell is shot or run into with Star power, should the kicked shells die.
Fireballs shot by Mario, are deflected by Hammers.
Also, I like that bullets and enemies don't despawn when you finish a level.
Fireballs shot by Mario, are deflected by Hammers.
Also, I like that bullets and enemies don't despawn when you finish a level.
Aah, no. Wasn't in the SMB. http://youtu.be/PadengKoayA?t=12m23sFranpa wrote:Fireballs shot by Mario, are deflected by Hammers.
Although, I think there still is a bug about this guys. Is it's just me who can't kill hammers by jumping onto them? Cuz you can kill them that was in SMB.
I say objects, that was "started" when player was near them should have ability to interact with other world, like a player himself. At least the objects in front of a player.Franpa wrote:Also, I like that bullets and enemies don't despawn when you finish a level.
Is that a bug, when you're a white guy, if u get hurt, u instantly become small. Not just big red?
Last edited by get8p on 09 Mar 2012, 09:29, edited 5 times in total.
(Are you serious!!!!)>(╯°□°）╯︵ ┻━┻get8p wrote:Is that a bug, when you're a white guy, if u get hurt, u instantly become small. Not just big red?
EDIT: Damn, xXxrenhoekxXx you beat me to it.
-
Innominate
- Posts: 1
- Joined: 09 Mar 2012, 09:31
I have an error that I managed to fix.
I pressed right on the "Select Mappack" menu (to load the DLC section). It displayed a message saying "Downloading 2 of 2" (or something like that) and then caused this error message to appear:
I should mention a few details in case they're relevant:
I pressed right on the "Select Mappack" menu (to load the DLC section). It displayed a message saying "Downloading 2 of 2" (or something like that) and then caused this error message to appear:
I should mention a few details in case they're relevant:
- I'm running 64-bit Windows 7 home premium.
- This is 1.4.
- I already had the first DLC, Science and Stuff, downloaded.
- I installed each of 1.2, 1.3 and 1.4 by overwriting the previous files (1.0, in the case of 1.2) and renaming the mari0_version.exe to just mari0.exe (though this shouldn't make a difference, I hope).
- The mappacks folder says that Escape the Lab (the second DLC I assume?) successfully downloaded the level entries for 1-1 through 1-3, but no other files. They all seem to be complete; each ends with the normal text (e.g. timelimit and stuff).
I have exactly the same error as Innominate and am running the same O/S. Deleting the DLC does not resolve it here.
If you test a Sub Level, the pipe to take you back to the Over World doesn't take you to the correct destination. This only happens within the editor.
Not a bug. Same thing happens in the NES game. :pRWLabs wrote:Try crouching, then start swimming. The graphic shows you swimming as if standing, but you're... I'm not phrasing this well am I?
1. Try crouching underwater.
2. While crouching, press the jump button to start swimming.
3. Go to the ceiling
4. Your head is in the wall.
Both clock-wise and counter clock-wise are present and working in my levels.Someone64 wrote:The rotating fireball blocks (clockwise only) are gone and harmless, -.- the block is there but not the deadly part.
OhmygoddoyouhaveevenhaveplayedtheoriginalmariohowhighdoyouhavetoBEEEEtodosomethinglikethatseriousely.get8p wrote:Aah, no. Wasn't in the SMB. http://youtu.be/PadengKoayA?t=12m23sFranpa wrote:Fireballs shot by Mario, are deflected by Hammers.
Although, I think there still is a bug about this guys. Is it's just me who can't kill hammers by jumping onto them? Cuz you can kill them that was in SMB.I say objects, that was "started" when player was near them should have ability to interact with other world, like a player himself. At least the objects in front of a player.Franpa wrote:Also, I like that bullets and enemies don't despawn when you finish a level.
Is that a bug, when you're a white guy, if u get hurt, u instantly become small. Not just big red?
-
TiagoTiago
- Posts: 101
- Joined: 05 Mar 2012, 07:44
I thought kicked shells would bounce of each other...Franpa wrote:I can somewhat confirm that kicking a shell into a walking koopa will kill both the kicked shell and the walking koopa. The kicked shell should pass through the walking koopa and continue on its destructive path. Only when 2 kicked shells collide, a kicked shell is shot or run into with Star power, should the kicked shells die.
...