Language…
5 users online: CONLUSH666, crocodileman94, George, ShadowMistressYuko, tired_ideabox - Guests: 78 - Bots: 93
Users: 67,694 (2,003 active)
Latest user: Sable Mage

Sprite and Player switch gate by pacmanboss256

File Name: Sprite and Player switch gate
Submitted: by pacmanboss256
Authors: pacmanboss256
Act As: 025
Includes GFX: No
Description: These blocks destroy sprites and kill the player in one switch state, and act as a blank tile in the other state.
Screenshots:
Rejecting this due to it being an unoptimized blockreator block. If you want to re-submit this or something similar, I'd suggest looking at the code it generates before posting it. Here are some general things to look out for if you decide to look at this again (and for future reference to learn from mistakes):

Instances of BRA Label, where Label only has a single RTL after it can be reduced to just an RTL immediately. This saves both bytes and cycles since the branch doesn't need to be stored in the ROM or executed during runtime. As an example. the BRA Label_0005 here could just be replaced with an RTL.
Code
MarioSide:
    LDA $14AF|!addr                ; \ If the ON/OFF switch is ON...
    BNE Label_0004                ; /
    JSL $00F606                ; > Kill the player.
    BRA Label_0005	
Label_0004: 
    LDA #$25                ; \ Make this block passable.
    STA $1693|!addr                ; |
    LDY #$00                ; /
Label_0005:                    ; > --------
    RTL


Next, the act-as specifies to use 130, yet every defined routine ends up setting itself to 25. You could change its act-as to be 25, then get rid of all the instances of setting itself as 25. Label_0004 from above could effectively be removed entirely, since the act-as would do the job for you.

Another optimization is that it inserts code for the wall feet and wall body states, yet a block like this would likely never need a handler for these states due to it killing the player. You can use db $42 at the beginning of the file to have these not be inserted.

Hopefully these notes are helpful to you in making better blocks in the future, because the concept seems really cool! I would also recommend trying to add user options at the top so they can make easy tweaks for their needs. Stuff like the switch type that triggers the block, what sprites will or will not be destroyed, and other things would all be good to consider.