It looks like uberasmtool was updated to have a "define_sprite_table" macro. When trying to import this file using UberAsmTool it complains about duplicate macro for "define_sprite_table". A quick find/replace for "define_sprite_table" in SA1SpriteForUberasmTool.asm and replace it with whatever name you want fixes the issue.
LDA !Freeram_PlayerInfoSaveBEQ .RestoreCodeEnd
PHX ;>X is still being used
REP #$20 ;>16-bit A
LDX #$02 ;>Start loop counter/What position to use
LDA $94,x ;\Adjust player position
ADC !Freeram_RelCoorWarp,x ;|
STA $94,x ;/
DEX #2 ;>Next index/position value
BPL ..Loop ;>Loop if 0 or positive
PLX ;>Restore X of something else.
I forgot to add a check if the warp is normal to skip displacing the player's position. I assume that I set the displace values to 0 when doing a normal warp, my bad.
LDA #$00 ;>A = #$00
CMP !Freeram_PlayerInfoSave ;\If regular warp, don't set player
BEQ .Return ;/info.
STA !Freeram_PlayerInfoSave ;>Clear itself so when switching to normal doesn't screw up.
that was ment to prevent applying the physics to the next level if other than teleport blocks.
The physics weren't the problem (I mean, hello, I can read ASM cdoes too). In fact, I never even addresses the UberASM code.
I rather meant the positions which are handeled by the patch instead of UberASM and it used to not check whether it was a relative teleport or not. I mean, if you still have got the old version (you know, before I accepted this patch) or remove the check, just do a regular teleport after a relative teleport and see what I mean.
For smoother transitions (as seen in e.g. Metroid where you still are in the same position you have entered the door), this patch is made for you. You might want to consider to use Horizontal Scroll Fix, though, as the blocks you place, are most likely be placed at the very end of a level.
I also have fixed a serious issue with the patch as it didn't take account whether it was a regular or relative teleport so it also moved Mario when the teleportation came through other means (like doors or pipes).
There also were some other, minor issues, namely that Yoshi always faces to the right and the ducking and sliding state isn't preserved.
Thanks, I've found a code that handles setting the player's position during warp, and by using RAM as displacement, I can override that position to rely on the displacement prior teleporting. It has to displace XY after the code gets 100% done calculating the coordinates, else there are bugs. Be careful with extending the blocks vertically, smw's screen X position is automatically set to the player's pos, but the Y position is set by level (Layer 1 Init Y pos). Luckily it isn't a major problem when there are no V scroll.