The problem: If Mario tries to jump while his base is overlapping a slope tile (any except 16E/191 and 17D/182) but he's not already standing on it, he will suddenly stand on the slope and won't jump. This looks odd and isn't very intuitive.
Is there a fix available for this behaviour, or maybe a custom slope block that doesn't have this quirk?
Works like a charm! Thanks so much!
I had found the slope pass fix before, but I never thought to apply it since the description mentions a different problem. It looks like the behaviour was changed as a side effect of making the intended bug fix work, so it's not advertised as fixing it in the patch section.
I've been investigating an extremely strange and specific bug in my hack. To sum it up, having a tile with ExAnimation in a certain spot in an extremely tall horizontal level breaks the goal circle animation in a completely different sub-level, turning it into a mess of black lines. It's bizarre, so I'm just going to list what I could narrow it down to after a lot of experimentation and hope that somebody has an idea of how to approach this:
- The hack is SA-1 (haven't tested without).
- The bug happens if there is a tile using level-specific ExAnimation on screen 1D at location 7,16 (decimal, I just counted the blocks) on layer 2. Yes, this is how specific it gets.
-- It doesn't happen if the tile is on layer 1.
-- It doesn't happen if the tile isn't using ExAnimation, though the specific tile doesn't matter.
-- I can have instances of the same tile literally everywhere else in the entire level except in this one spot.
- The level uses Horizontal Level Mode 19. The SMW Level Mode is 1F (translucent layer 2), but it doesn't seem to matter as long as there's a layer 2.
- Layer 2 scrolling speed doesn't matter.
- Mario's entrance position doesn't matter.
- Happens with and without HDMA effects.
- The level number doesn't matter.
- The level and location of the goal don't matter. Once Mario has been in this level, the goal animation will henceforth be broken when he touches a goal anywhere. This happens consistently.
It's by far the strangest thing I've encountered yet. Does anyone have any ideas on what it could be related to, or what to do next to help pinpoint it?
EDIT: Further testing:
- I couldn't replicate the problem in a regular base rom.
- This happens even after deleting everything from the level apart from the one layer 2 tile and a way to get to the next sub-level.
- It happens in other horizontal level modes that stack screens on top of one another, with the requirement always being for the animated tile to be at the same specific spot on the final sub-screen.
It's probably hopeless looking for an answer to this, given the narrow requirements and not being able to do it in a base rom. It just drives me crazy that I can replicate it consistently in my rom when it seems like there should be no correlation between what I'm doing and what it breaks.
All I can think of is some weird obscure bug between Lunar Magic's screen-stacking level modes and SA-1 that's causing the animated tile to overwrite something it shouldn't, but I don't know how I would find out.
Unfortunately, I'm also having trouble replicating it in another rom. I don't want to share my hack at this point, and I don't know what the key difference may be that enables this behaviour. I never changed the goal circle in my hack and the patch to disable fade-to-black didn't do the trick, so it's bound to be something totally unrelated. It's like looking for a needle in a haystack without knowing what a needle is.
I suppose I could port everything to a new rom, but since I don't know what patch or resource may have gotten me here and I haven't done anything weird (to my knowledge) since I ported to SA-1, it would likely just show up again once things have been re-applied. :/
I'm trying to use the "Tides, high and low" with advanced Layer 3 bypass active in Lunar Magic (for the CGADSUB setting). However, the bypass disables their movement, and while the horizontal scroll is easy to fix, all the vertical scroll settings seem to go in one direction only.
Is there a way to have the tides rise & sink like they normally do?
EDIT: I seem to have solved this by setting the CGADSUB in a UberASM instead of using Lunar Magic's bypass, but it would have still been interesting to know if there's any way to have the bypass active and get the default rising & sinking behaviour. The code I used was this:
I'm using the "all Yoshi coins collected" flag for something else in my hack and saving it for each level via BW-RAM Plus patch. I'm also using the overworld marker that shows a coin for levels where the flag has been set.
This is all working fine, except there's a level that uses actual Yoshi coins for a coin gate, and if the flag has been set, those Yoshi coins naturally won't appear. I'd like to force them to appear whether or not the flag is set, but it seems that the address in the ROM Map that's supposed to do this (3 bytes at $00F354 to EAEAEA) merely prevents them from setting the flag in the first place and has nothing to do with their spawn behaviour. Using Map16 is also not an option, because then the coins respawn on re-entering the room.
Does anyone know how to make the Yoshi coins spawn regardless of the flag being active?
Thanks so much! I wonder why that address didn't come up when searching for "dragon coin" in the ROM map.
In fact, it still doesn't! I can search it up in various ways, up to "ragon Coin creation routine", but as soon as the search term starts with "Dragon ", it no longer comes up as a result. (Try it, it's easy to reproduce.) I think someone should look into that.
I've been curious about ways to shorten the delay before a Dino Torch breathes fire for the first time after spawning, but I'm quite confused where this timer is initially set.
Looking at the documented Dino Torch code in Bank03, it seems to use $1540 (which is usually a stun timer) both for the duration of breathing fire and the delay until the next time it does so. At ROM $039D4B, it stores #$40 in the timer as it finishes up the attack, which indeed changes how long it takes to breathe fire again.
But what I don't know is how it determines when to breathe fire for the first time. It seems like it should initialise the $1540 timer to something when it spawns, like the Sumo Bro., but if that's the case, I don't know where this happens. The Init code in Bank01 only sets $151C, which is the flame length.
I feel like I'm missing something crucial. Does $1540 have a default value for every sprite that spawns, so the Dino never sets it?
Ah yes, I see how it works now. Thanks! The documentation says this is the number of frames before the Bob-Omb explodes, but it's actually the time before it stuns itself. Really puts into perspective how sluggish the Dino Torch is to attack.
May need to try the hijack.
Not sure... Going by files I can find, the oldest SMW hack seems to be the original Demo World (not TLC) tied with something called "Super Mario Challenge" from 2002. Following those is some nonsense that's not very good before eventually moving to things like SMW+ and The Second Reality Project.
First non-SMW hack is harder to say, but I downloaded an SMB3 editor called Mario Improvement 3 before I even knew anything about emulation, so it's quite possible that the first "hack" I played was my own attempt at editing that game.
Darkwing Duck is a horizontal (and sometimes vertical) scrolling action game. You control the character "Darkwing Duck" using your TurboPad Controller. Play is based on the "damage" system. Each time you defeat an enemy, you score points.
I was on Acmlm's Board regularly way back as a young teenager, but I never had an account or anything. I would usually lurk on forums as a guest and keep up with things without ever joining or posting, for multiple reasons, mostly social. Of course, I'm barely on this site either.