Language…
18 users online:  AmperSam, Carnalwillow, crocodileman94, DanMario24YT, EvilAdmiralKivi, h4shcat, Hayashi Neru, Jaiden, JezJitzu, MorrieTheMagpie, quantumcoder,  Segment1Zone2, ShadowMistressYuko, signature_steve, simon.caio,  Tahixham, toady, TonyversoTV - Guests: 264 - Bots: 315
Users: 64,795 (2,378 active)
Latest user: mathew

Carry Sprites Through Doors and Pipes by wiiqwertyuiop

File Name: Carry Sprites Through Doors and Pipes
Submitted: by wiiqwertyuiop
Authors: wiiqwertyuiop
Tool: Asar
Requires Free Space: Yes
Bug Fix: No
Featured: No
Description: Let's you carry sprites between rooms, whether Mario is holding them or they are in Yoshi's mouth, without them disappearing. I also changed some of SMW's sprites so they don't re-spawn when you bring back to the same room.

Also works with custom sprites.
Screenshots:
I "couldn't" get past the patching because it seems like all of the freespaces aren't protected by an autoclean. I would be nice to fix one leaked freespace but given how there are many of them, it is a rejection reason for me and others of the ASM team.

On a side note, I recommend you to merge all of the freespaces into one single block (so that you only need one autoclean). You also might want to use defines and conditionals whether or not certain functions are added (though it's optional) and I really recommend you to use pushpc and pullpc if you merge them into a single freespace böpcl that the orgs and the freespace code is put . And possibly use "@includefrom AllowCarry_Main.asm" so that the files can only be patched with AllowCarry_Main.asm (they were created that way, aren't they, and allows you to patch them seperatily but it's IMO still quite stupid). That, or you create an ASM file which includes the other files where you can activate them or not.
Tip: Use "assert" which works similar to "if" but calls an error if the conditional value is zero (e.g. "assert 0, "Message") to check if one of the has been used.

But please, try to fix the freespace leaks before you resubmit it. SpriteID.asm might be the trickiest one given that it doesn't feature any long address in a fixed area (i.e. an autoclean after an org, doesn't matter if in the first 512KiB in the ROM or beyond that) it points to the routines to the routine (maybe add some dummy JMLs à la Shared Subroutine patch?) but you still should fix it nonetheless.