Views: 14,248,058 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
05-08-21 12:35 PM

Main - Posts by dy

Pages: 1 2
Posted on 04-02-18 03:42 AM, in SM64DS Editor Help Thread - Post your questions here Link | #93919
Hi, does anyone know how to prevent objects/enemies from respawning once defeated/broken (eg, bob-ombs, pirahna flowers, wooden crates)?

The object parameters don't seem to deal with this, so I'm guessing an ASM patch is required. Does anyone know the memory address of the respawner function? (Fingers crossed there is a general respawner function which can be disabled, rather than having to find and disable individual member functions for different objects).


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

(post deleted) #93939

Posted on 04-04-18 09:30 AM, in SM64DS Editor Help Thread - Post your questions here (rev. 3 of 04-04-18 09:44 AM) Link | #93954
Yes!! Mini breakthrough for Yoshi lovers - figured out how to make Yoshi able to break red brick blocks and defeat Boos by ground pounding!

Following Fiachra's suggestion of setting a breakpoint on the SpawnActor method (0x02010E2C), which is triggered whenever a coin or other object is spawned, then tracing backwards - managed to figure out that 0x021162C8 is run when either Yoshi/Mario stomp on a Boo, but that the 3 conditional instructions in the red box only run for Yoshi.

So, by changing those 3 instructions to "nop" - Yoshi can ground pound Boos!! I'm guessing r1 is reading some kind of collision or vulnerability flag.


It's a bit more straightforward for red brick blocks (below image tutorial courtesy of Fiachra), which have an "OnGroundPounded" callback that enemy objects like Boos/Goombas don't seem to have.

Easiest way is to change the instruction at 0x020B3834 to "mov r2, 0h", which tricks the brick to read the player as being Mario.


Boo code is in overlay 63 and brick code is in overlay 2 (has anyone made an overlay search tool yet?)

Now to look into Yoshi's crouch kick / slide kick for Boos, and then other enemies/objects (eg, Bullies being knocked back when hit by egg, etc)! EDIT: Also doesn't work for the slightly bigger Boo with the cage - more work to do!


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-05-18 12:05 AM, in Editor development Link | #93960
Is it just me, or does SM64DSe cause it to freeze on trying to load the "Dire Dire Docks" level?

Using EUR ROM and latest SM64DSe off github (R104). Completely clean ROM - no changes other than opening with SM64DSe. Tried with both an old save and new game. Freezes whether entering via map select or through the castle normally...


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-09-18 07:07 AM, in SM64DS Editor Help Thread - Post your questions here Link | #93998
Posted by natnew
Is there a way to make the player start with keys to the locked doors without them doing anything, or any way to get one without a long cutscene? Or just allow all characters to enter 8/30 star doors without keys (only Mario can enter them before the respective Bowser is beaten)

Here are some AR codes for the EUR rom that should do what you want:

Open All Doors
52144D50 E1500001
02144D44 EA00007B
02144E14 EA000047
02145CD8 EA000041
D2000000 00000000

Open Star Doors as Anyone
52145CB8 A3A00000
02145CB4 E3A01000
D2000000 00000000

Open Doors Without Stars
52145CA4 E3A03902
02145C98 E3A000FF
02144D54 EA000018
D2000000 00000000

Always Have Door Key
52144E28 EB000055
02144E24 EA000037
D2000000 00000000

PS: for the 12 and 30 star Bowser doors, you don't have to defeat Bowser first before anyone can enter (you just need Mario to open the door). Yoshi's flutter jump is awesome for these levels, as well as ability to grab hard to reach coins with his tongue.


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-09-18 08:54 PM, in SM64DS Editor Help Thread - Post your questions here (rev. 9 of 04-24-18 08:18 PM) Link | #94003
Once you learn how to interpret AR codes (http://nintendq.forumotion.com/t45-action-replay-code-types), it should be fairly easy to convert the to a ROM edit.

For example, the "Open Star Doors as Anyone" code is saying:
    52145CB8 A3A00000 // if value at address 02145CB8 is "A3A00000"
    02145CB4 E3A01000 // change the value at address 02145CB4 to "E3A01000"
    D2000000 00000000 // end the if-block

So now you just need to find where in the ROM to make this change. For addresses in the range 0201xxxx it's pretty easy, just drop the 2 and you have the offset for the ROM file. However, the 021xxxxx address tells me it's likely in an overlay (which are loaded and unloaded by the game as needed), so it's a bit trickier to find.

Below memory addresses assume the EUR rom, but same process applies for US/JAP roms (you just need to find the right AR codes for your ROM):

  1. Open the ROM in no$gba debugger (freeware, available here: http://problemkaputt.de/gba.htm. Make sure to get the debug version).

  2. When inside the castle, go to memory address 02145CB8 and note that, yes, the value at the address is "A3A00000" (this means we currently have the correct overlay loaded in-game):

  3. [thumbnail]

  4. Make a note of a couple of the values in that area - we'll need to search the overlays one by one until we find those values. Note also you need to reverse the order of the bytes (eg, "12345678" will appear as "78 56 34 12" in the ROM/overlays).

  5. You can use SM64DSe to extract the overlays. Make sure to decompress the overlays first before dumping ("More" > "Decompress Overlays Within Game").

  6. Now open each overlay in a hex editor and search for the relevant values - I usually pick a sequence of about 3 values to reduce risk of false positives. (UPDATE: just found out you can narrow down which overlays to look in by looking at arm9ovt.bin, see this post). I found the relevant values in overlay 100. Note how the values in the green/orange/red boxes match up against the values in no$gba (reversed bytes):

  7. [thumbnail]

  8. Now the AR code says we want to change the value at address 02145CB4 (the red boxes). From the above process, we now know this is offset 0x4F34 in overlay 100.

  9. Last step, create a new patch using SM64DSe ("More" > "Additional Patches"), making sure to tick the "Apply to Overlay (ID)" box and specify "100" in the field next to it. Now, in between START EUR and END EUR type the following:

    • 00004F34:
      00 10 A0 E3

    This tells the patch to change offset 00004F34 of overlay 100 to the specified value (note again how the bytes are reversed from the value given in the Action Replay code). Then just save and apply patch!


    - ASM resource for customising behaviour of player/objects/levels
    - NSMBe with direct overwrite feature

Posted on 04-14-18 04:06 AM, in SM64DS Editor Help Thread - Post your questions here (rev. 4 of 04-14-18 10:42 AM) Link | #94057
Posted by Summoned_Blade
I'm trying to change the amount of stars required to open the big star doors and was wondering if it is possible. If it is how would I do it.

@Summoned_Blade: Saw your post last week, just took me a while to get around to it. Just figured it out!

1. In SM64DSe, go to the "ARM 9 Overlays" tab and decompress and then extract Overlay_100
2. Open in a hex editor and go to offset 0x7610. The values you want to edit are as follows (remember to convert to hexadecimal): https://i.imgur.com/a7Fiph6.png
3. Open the SM64DSe text editor and change the following entries accordingly (note the use of hexadecimal for the "You need __ more" code): https://i.imgur.com/fD809a4.png
4. Finally, go back to the "ARM 9 Overlays" and replace Overlay_100 with your edited file. And your done!

Note: Editing the number of stars required for the 80 Star Door doesn't affect the endless stairs (there must be another check hardcoded somewhere). Also, if you change the number of stars required for the 80 Star Door to anything other than 80 (0x50 in hexadecimal), it will behave like the other Star Doors and not open unless you have the required number of stars. So change the text appropriately.

Update: Figured out how to change the star/character requirements for the Endless Stairs as well. See: http://kuribo64.net/board/thread.php?id=3550


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-14-18 10:23 AM, in [ASM Resource] Customising behaviour of player/objects/levels (rev. 24 of 05-07-18 09:08 PM) Link | #94061

Firstly, huge thanks to the team behind SM64DSe and the ASM Patch Templates, as well as everyone who's contributed to documenting the object parameters, memory addresses and subroutines. What I have found and documented here wouldn't be possible if it wasn't for the amazing quality of research, documentation and tools available to the community. Special thanks also to Fiachra who helped me get started and inspired me to learn ASM hacking.

This thread is intended to collate discoveries on how to customise certain player, object and level properties/behaviours (in ways that can't be changed using SM64DSe alone). It is not a substitute for the existing ASM resources, which are invaluable if you want to create ASM hacks or do your own research.

If you've made any discoveries of your own which fit with this thread, please feel welcome and encouraged to share!

Getting Started with ASM

In order to understand and use the information provided, you will need some basic ARM ASM knowledge. This is not intended to be a general ASM help thread, but don't worry, there are plenty of tutorials available online. I personally have very little programming experience and knew zero ASM just 2 weeks ago, but learnt a lot from this tutorial (30 minute read) and playing around with the no$gba debugger (see below).

Useful programs:
  1. ASM Patch Templates and associated programs
    Allows you to change or create custom code for the game. The most updated templates are included with the latest SM64DSe, but you will still need the associated programs in the above link. The header files and symbols.x included with the templates contain a lot of useful memory addresses and offsets for researching and writing your own code (there are 2 "versions" of the template docs - v2 by mibts has a lot more features, but v1 also has some helpful stuff and is probably more beginner-friendly).

  2. Modified version of NSMBe
    Optional - allows you to directly overwrite existing code rather than jumping to new code (useful for changing data tables and pointers).

  3. no$gba debugger
    Allows you to change and test code live in-game, or to set breakpoints and conduct your own research. Make sure you get the debug version.

Additional tips:
  • When writing hooks with the ASM Patch Template, you need to specify the overlayID in hexadecimal (whereas the overlay numbers documented below are in decimal).
    Eg, to use the 'nsub' hook for something located in overlay 98 (0x62) you would write "nsub_02xxxxxx_ov_62".

  • In ARM ASM, ldrb/strb means load/store byte (1 byte), and ldrh/strh means load/store halfword (2 bytes). Default is 4 bytes, without the b/h suffix.

  • In no$gba, you can change data values by going to the memory location and changing the instruction to "dcd 0xXXXXXXXX" (where the X's are the data you want).
    Don't use "dcd" when compiling code for the ASM Patch Templates though - use ".word", ".hword", or ".byte" instead.

Documented Discoveries

OK, now onto the good stuff! This post will be updated as new discoveries are made.

    Yoshi: can punch and grab

    Hold "Y" (sprint) while attacking to punch/grab/dive: this post

    Player: speed and jump height

    See this post

    Wing Cap: who can get Feather powerup

    There are several parts to this:
    1. When a Feather exists, the game constantly checks whether the player is Mario and immediately despawns the Feather if not (eg, if player loses their Mario disguise)
    2. When the Feather is collected, the game again checks if the player is Mario (if not, the Feather disappears without giving any powerup)
    3. To spawn a Feather, you can either use the "! Block VS" object or change who "? Blocks" give Feathers to (for "? Blocks" that normally only give Feathers to Mario).

    Despawn loop check: here
    Whether to give wings when collected: here
    Whether relevant "? Blocks" spawn Feathers or Power Flowers: here

    Power Flowers: who can see Power Flowers in mirror room

    Unfortunately crashes when collected by Mario/Wario in Castle 2F, and there is no reflection for Yoshi's fire breath. But it seems to work properly in painting levels. Including this in case anyone wants to use static Power Flowers in custom/painting levels only.

    Visibility of static Power Flowers: here

    Brick Blocks / Black Brick Blocks: who can break

    When ground pounded: here
    When kicked or sweep kicked: here
    When punched: here
    On explosion: here

    Ice Blocks: can be shattered

    See this post

    Boos: who can defeat

    On any attack that can normally defeat Boos: here

    Bob-ombs: whether to reappear and what to spawn when defeated

    Whether to reappear: here
    What to spawn: here

    Piranha Plants: whether to reappear and what to spawn

    When defeated: here

    Wooden Crates: whether to reappear and what to spawn

    When broken: here
    When swallowed by Yoshi: here

    Yellow Coins / Blue Coins: whether they disappear

    Countdown timer: here

    Object Draw Distances

    Easy way to change for all or specific objects: here

    Something easy: you could set a fixed draw distance for everything (r2 = 0x600000 seems to give good results without killing the frame rate)
    Something fancy: offset 0xC (2 bytes) of the object's address (r4) is the ActorID of the object - so you could check this to set different draw distances for different objects

    Bowser Star Doors / Endless Stairs: star and character requirements

    Bowser Star Doors: here
    Endless Stairs - music/lighting effects: here
    Endless Stairs - whether can get to top: here

    Change when you get "recovered X stars" messages: here

    Power Stars: whether to continue or exit level after collecting

    100-Coin Stars: here
    Level type: here

    Level and level transition behaviours

    See this post

    Allows you to do things like:
    • create mega levels with more than 8 Power Stars
    • set the StarID for castle/boss maps - so these can have different configurations after an event of your choosing has occured
    • 100-coin stars in secret/boss levels

Conducting Your Own Research

For those who are interested in doing their own research and wondering how I discovered these, the process essentially involves:
  1. Finding a suitable starting breakpoint, eg Actor::Spawn() function (which is called any time something is spawned, such as a coin).

  2. The ASM Hacking Templates (especially symbols.x and SM64DS_2.h from v2) are fantastic resources of currently known data locations, subroutines and their memory addresses. Action Replay codes can also be very helpful, if there is one that does something similar to what you want. Lastly, you can find addresses of object-specific callbacks (eg, OnGroundPounded(), OnKicked(), etc) by following steps 1-8 of Fiachra's tutorial for finding an object's constructor - after the constructor address, you'll see a long list of more addresses (which are the addresses of the various callback functions).

  3. Either tracing backwards through from the breakpoint to figure out where and how the game determines whether to go to that piece of code, or tracing forwards from the breakpoint to find when the game checks for something (eg, type of character).

  4. You'll need some ASM knowledge and a bit of creativity/patience. Tracing backwards involves looking at r14 (LR) to find earlier code that called your breakpointed code (and repeat if necessary). Unfortunately sometimes code uses "b" jumps rather than "bl" jumps (which don't store the return address to r14), so you might end up further back then you wanted and then have to step forwards. For tracing forwards, you can use "F7" in no$gba to step through code line by line (the debugger helpfully tells you the value of registers and whether conditional instructions evaluate to 'true' or 'false' as you step through). You can also use no$gba to change code on the fly to see if it changes what you want to change. Chaining breakpoints and conditional breakpoints can be very helpful (see this post for an example).

See here for how to set different types of conditional breakpoints (thanks to Fiachra for the link). You can also create breakpoints which are triggered whenever a memory address is read or written to (this can be really handy) - the previous documentationis a bit off for these though, so see here instead.

Lastly, once you've found what you are looking for, follow steps 3-5 in this post to find which overlay it appears in.


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-14-18 06:47 PM, in First Person View [v0.1 RELEASED] Link | #94067
Hey StarPants, it sounds like you're trying to put the camera in front of the player?

I haven't tested this, but I remember from looking at the Draw Distance function that if an object is behind the camera, it treats its distance as 0x7FFFFFFF (and so fails the draw distance check and isn't rendered). Maybe that's what's happening to the Player object here.

Try making the branch at 0x020110EC unconditional (or use the "Objects Always Visible" patch in SM64DSe's additional patches) - this will kill your frame rate, but if the Player becomes visible, now you know what's causing it. To fix, just check if r4 (object address) is the Player's address (the address stored at 0x0209F394), and if so make the relevant branch irrespective of draw distance.

PS: just read your post again - previously I think you were just having trouble with the Player object being invisible, is it now affecting all objects?


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-16-18 08:20 AM, in First Person View [v0.1 RELEASED] (rev. 4 of 04-16-18 08:24 AM) Link | #94092
StarPants - how did you go with the Objects Always Visible patch?

I was playing around with camera settings and discovered 2 things:

1. You can create a quick and dirty "sort-of" first person view (actually 3rd person, but it will mostly follow the player) by going into the level editor > "CLPS" and:
(a) changing all the ViewID entries to 63 (so the camera always follows you rather than trying to move to any pre-defined camera angles)
(b) changing all the Camera Type entries to either 0 or 6 (0: camera rotates slowly to face in the same direction as the player, 6: camera only rotates when the player is moving)

2. While I was doing the above, I noticed 2 times when the camera would still do its own thing (must be hardcoded, there might be more scenarios too). In the Bowser boss battles, and just after you come through an intra-level door (one that takes you to another area in the same level, eg painting room doors). Just after you come through such a door, the camera gets really close and rotates really FAST to face whichever direction you're facing (eg, try coming through a door, then turning around without going back through the door).

If you could make the camera do that all the time, it'd probably give you a pretty good first/third person view mode.

Maybe you could try:
1. setting some breakpoints to work out what function is doing that fast camera rotation
2. breakpoint all the times the camera position/angle is adjusted - and click through to work out which is the last one that runs before the frame updates (eg, do it somewhere where there's a spinning coin or something)
3. create a hook somewhere after that which calls the function you found in #1


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-16-18 09:30 AM, in First Person View [v0.1 RELEASED] Link | #94094
No - stm instructions are 'store multiple', so that would be a problem if you were nop'ing those!


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-16-18 10:46 AM, in First Person View [v0.1 RELEASED] Link | #94099
Also, what exactly did you do to get those memory addresses in your first post?

Some of them trigger whether or not the camera position/angle is changing. And the memory addresses that they write to are all over the place - I set a read breakpoint on some of the memory addresses they write to, and they don't seem to correlate with the camera position/angle...

Do you know the actual memory address where the camera angle/rotation is stored?


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-17-18 12:41 AM, in First Person View [v0.1 RELEASED] (rev. 4 of 04-17-18 01:22 AM) Link | #94113
Hey, that's pretty clever - I didn't think of that.

In the end I managed to find it by setting a breakpoint on INPUT_PERSISTENT (0x0209F49C) to see how the game handled rotating the camera when the L Button is pressed - the 2 relevant addresses were offset 0x80 and 0x8C of the camera object. That's when I realised you can use SM64DS_2.h to work it out, you just have to back-calculate it using sizes of known data types:


Knowing that will make research a bit easier going forward!! Be mindful that the camera object address changes for different levels though, so best way to get the 'pos' and ''lookAt" vectors is by getting the camera's object address (which is the address stored at 0x0209F318 according to symbols.x), then adding the relevant offset.

You did do something not so clever by the way... those instructions you nop'd aren't only used for updating the camera vectors (set a direct breakpoint for "0203B710" and look at 'r0' each time it's triggered, you'll see what I mean - it gets called a LOT to store things to all sorts of different addresses). No wonders everything was going haywire!! 😂

Anyway, I think I've found a good place for you to hook your code. Try 0x0200DA04 (I found it by setting a write breakpoint on INV_VIEW_MATRIX_ASR_3 - it is written to in one of the standard matrix math routines, so I had to trace backwards a bit to find the function that was updating the view matrices). It is called once a frame, and after the camera vector gets updated (which makes sense, since it would be updating the view matrix based on where the camera is). (EDIT: 0x0200DA04 is the start of the function, but not sure if it's safe to hook there as it is saving r14 (LR) there. Maybe hook at 0x0200DA0C instead.)

Before you go to all the work of making a first person view tied to the player's head bone though, try the following. I made a quick patch to trick the game into thinking you are always holding the L Button.

b 0x0200A5F8

b 0x0200A628

b 0x0200A640

ldr r1, [r8,#0x110]
add r0, r8, #0x100
ldrsh r1, [r1,#0x8E]
b 0x0200A650

add r1, r1, #0x8000
strh r1, [r0,#0x9E]
b 0x0200A660

Then go to one of the harder platforming levels (eg, Goomboss or Bowser) and see if you actually like the way the camera moves - I personally found it quite disorienting, because you turn so quickly when you're not moving and you can't use the mouse to look around like in FPS games. Also, try wall jumping. I imagine the effect will be even more pronounced in proper first person view, because the camera will move even faster. Can you imagine trying to control Luigi's helicopter jump??


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-18-18 02:48 AM, in SM64DS Editor Help Thread - Post your questions here Link | #94118
Here is the function that calls checks how many stars the player has and chooses which message to display (it's in overlay 2):


The numbers in red are in hexadecimal and should look familiar. It's basically a giant switch table - bgt means goto if greater than, bge means goto if greater than or equal, blt means goto if less than, beq means goto if equal.

It's a fair bit of work for not much gameplay value. Alternatively, just change the instruction at 0x020C6E38 to "b 20C6EB4" (unconditional goto) and this will make it simply not display any messages when you get 1/3/8/12/30/50/80 stars.

If you don't know how to make ASM hacks yet, see the ASM Hacking section of the stickied tutorial: http://kuribo64.net/board/thread.php?id=2319


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-20-18 09:41 PM, in [ASM Resource] Customising behaviour of player/objects/levels (rev. 15 of 04-26-18 10:59 AM) Link | #94134
Holy crap!!!

Did you know Yoshi has fully functional punch/kick/dive/grab attacks and animations!?

Here's how...

    Yoshi: can punch and grab

    How the game decides whether to perform a 'punch' or 'eat' attack: here

    Here's a quick patch for ASMPatchTemplate which allows Yoshi to use both his new and old attacks (hold "Y" while attacking to punch/dive/grab, etc):



      @ check if character is Yoshi
      ldr r0, [r4, #0x8]
      cmp r0, #0x3
      bne 0x020DDEDC

      @ approach used by the game to get "INPUT_PERSISTENT"
      ldr r1, =0x020A0E40
      mov r0, #0x18
      ldrb r2, [r1]
      ldr r1, =0x0209F49C
      mul r0, r2, r0
      ldrh r0, [r1, r0]

      @ choose attack depending on whether "Y" is pressed
      ands r0, r0, #0x800
      beq 0x020DDEB8
      b 0x020DDEDC

    To switch to hold "Y" for eat attack, just change the "beq" to "bne" (but the current setup feels more natural for dive attacks while sprinting).

PS: I've also discovered how to change the following:
  1. Whether a Power Star sends you back to the castle or lets you continue
  2. Whether or not the course star select / load screen is displayed
  3. Which StarID to enter the level as, without the star select screen
  4. Which type of pause screen and congratulations text used for different levels
These should make it easier to create levels without being as constrained by the ActID types that the default game uses (eg, you could create main levels without a star select screen so that the player doesn't know how many stars there are, like with the secret/boss levels). Being able to set the StarID without the level select screen also makes it possible to have castle/boss maps change after an event has occurred (without hacking individual objects).

I'll post these here once I've documented them properly (soon)!


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-21-18 03:49 AM, in [ASM Resource] Customising behaviour of player/objects/levels (rev. 4 of 04-21-18 08:54 AM) Link | #94136
Posted by StarPants
Nice! How did you discover Yoshi's secret abilities in the first place?

Similar process to all the others - this one was actually surprisingly straightforward:
  1. I set a read breakpoint on INPUT_1_FRAME to see when the game checks for "A" keypress (note that Yoshi doesn't keep sticking his tongue out if you hold "A" so guessed it was checking INPUT_1_FRAME rather than INPUT_PERSISTENT)
  2. Got the value to look for through DeSmuME RAM watch, then cycled through the breakpoints until I found it check for the "A" key (luckily there weren't many and didn't have to look very hard)
  3. While still breakpointed at the "A" key check, I set a read breakpoint for the acting character type (Player object address + 0x8) to see when ths game next checks who you are playing as
That took me straight to the spot in the image I posted. It branches off if the player is not Yoshi, so I changed it to an unconditional branch to see what would happen. Fully expected it to do nothing or crash due to lack of animations, etc, but can you believe it... IT WORKED!!!

EDIT: Fixed code for YoshiCanPunchAndEat - I accidentally stuffed up the Yoshi check, so it was affecting every character!


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-21-18 12:21 PM, in [ASM Resource] Customising behaviour of player/objects/levels (rev. 4 of 05-07-18 09:10 PM) Link | #94139
EDIT: I think you might be right. His punch seems to be set to be much weaker than any other character's (Goombas don't go very far at all), but he can run quite fast while carrying things.

It's a bit of a mixed bag in terms of consistency though. He can throw Big Bob-omb pretty far, but can't seem to throw crates as far as Luigi. Also if you bring lost little penguin to Mama Penguin with Yoshi she won't recognise it and just give the "have you seen" speech... Will have to figure out how to fix all that.


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-21-18 12:47 PM, in SM64DS Editor Help Thread - Post your questions here (rev. 3 of 04-21-18 12:47 PM) Link | #94140
There's an Action Replay code which lets 100 Coin Stars spawn in any level. See my post a few pages up on how to convert AR codes into ROM changes (for the last step, rather than create a patch you can just edit the overlay directly since you know how to do that).
    Can Collect 100 Coin Star Inside Castle
    520B1920 E350000F
    020B191C E3A0000E
    D2000000 00000000

To change when the "You've recovered __ Power Stars" messages appear, you don't have to use the ASM Patch Template... You can use a similar process as the one for converting AR codes to find the offset of each number I circled in red (remembering to reverse bytes as described), and manually hex edit each of those entries.

As I said, a lot of work though and easy to get things wrong...

The ASM Patch Template takes a while to set up and get used to, but it lets you insert new code or change existing code without having to use a hex editor, reverse bytes or find the overlay offset. Well worth it if you want to look into making more ROM changes in future (see the link in my signature for some cool things you can do with ASM - for example, did you know you can make Yoshi punch/grab/throw enemies!? I just discovered it today!)


- ASM resource for customising behaviour of player/objects/levels
- NSMBe with direct overwrite feature

Posted on 04-22-18 10:58 AM, in [ASM Resource] Customising behaviour of player/objects/levels (rev. 7 of 04-26-18 10:15 AM) Link | #94149
As promised, here are some discoveries which allow you to customise the behaviour of level transitions and Power Stars.

Might not sound very exciting at first, but it allows you to do things such as:
  • create mega levels (with persistence across several ActIDs) - so you can have more than 8 Power Stars in that "level"
  • set the StarID for castle/boss maps - so you can check if something has happened, then load the map with different objects/warps afterwards
  • choose the behaviour of Power Stars, etc without being constrained by the ActID type
  • have more levels within levels (like Luigi's painting in Boo's Haunt)

    • Power Stars: whether to continue or exit level after collecting

      100-Coin Stars: here
      Level type: here

      Level: whether to display star select screen

      Level type, moving between levels: here
      See below on how to set the star number without the star select screen

      Level: set star number for level

      See here
      Allows you to create multiple setups for the secret/boss/castle levels, or force the star number if you don't want courses to have star select screens

      Level: persistence across levels

      Coin count and object respawns: here
      Note: some objects are not added to the death table, so will respawn when moving between sublevels (eg, Brick Blocks in Cool Cool Mountain after you return from the slide)

      Level: attainability of 100-Coin Stars

      Level type and coin requirements: here
      (Thanks to whoever created the Action Replay code for the offset)

      Whether and when to display "recovered X stars" text

      See here

      Pause Menu: whether can "Exit Course"

      See here

      Pause Menu: make Main Castle use course/level pause screen

      Change the instruction at each of the following addresses from cmp r0, 0x1D" (castle ActID) to "cmp r0, 0xFE" (or another unused ActID):

        0x0202DC74 - loads background for course/level pause screen (when entering castle level)
        0x02029550 - shows text for course/level pause screen
        0x020252B4 - don't show star map on top screen
        0x020280C8 - fix glitch when entering Options screen
        0x02028B74 - fix glitch when leaving Options screen
        0x02027FD4 - fix glitch when leaving Controller Modes screen

      Pause Menu / Star Text: make main courses like secret/boss levels

      To make pause menu only show the course name (like with secret/boss levels), and make the text when you leave with a Power Star like that for secret or boss levels:

        - set r6 to either 0x12 or 0x15 instead (same effect for pause menu, for exit text 0x12 = "[course name] COMPLETE" and 0x15 = "another castle secret star CLEAR")
        - store r0 (the level's real ActID) to a global variable

        - get the stored (real) ActID and add to r0 instead (this makes it display the correct course name)
        - leave the value of r6 untouched (ie, still 0x12 or 0x15)

        - make the jump unconditional (removes "score" from pause screen)

        - conditional branch - if true, displays "Congratulations" bubble text on exit (like after boss fight)

        - jump to 0x0202457C (saves highscore but doesn't display "Highscore" bubble text)


    - ASM resource for customising behaviour of player/objects/levels
    - NSMBe with direct overwrite feature

    Posted on 04-23-18 09:33 PM, in First Person View [v0.1 RELEASED] Link | #94173
    Hey, just tried this - what an experience! I'm actually really impressed with how well you got it to follow Yoshi's head movements (a little too well haha - Yoshi needs to hold still!)

    You are right though about it not being as disorienting when the camera's up close. You can try my "L button held down" code again with the CLPS CameraBehaviour set to 11 (the close up camera) - apart from not following the player when it jumps and not keeping up with spin jumps, I actually think it works quite well. It gives a similar feel to FPV in that it puts you in Yoshi's perspective and makes the world and objects look bigger (like they would to Yoshi), but makes it a bit easier to land jumps and you can also still see the character (which I quite like, but not sure about you).

    Good work!


    - ASM resource for customising behaviour of player/objects/levels
    - NSMBe with direct overwrite feature
    Pages: 1 2

    Main - Posts by dy

    Page rendered in 0.029 seconds. (2048KB of memory used)
    MySQL - queries: 22, rows: 141/141, time: 0.020 seconds.
    [powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
    © 2005-2008 Acmlm, Xkeeper, blackhole89 et al.