Name: | Portable Orb of Teleportation |
Authors: | algae5, wye |
Added: | |
Tool: | PIXI |
Type: | Standard |
Dynamic: | No |
Disassembly: | No |
Includes GFX: | Yes |
Description: | The Portable Orb of Teleportation, or P.O.O.T. is a useful sprite for teleporting the player around. Pressing L or R will teleport the player to the orb, and holding a direction during the teleport will cause the player to be launched in that direction after the teleport is finished. The P.O.O.T. is a single use sprite that destroys itself after being used once. Based upon WhiteYoshiEgg's Carryable Pipe Sprite. |
Tags: | boost carryable lorom pacifist sa-1 |
Comments: | 17 (jump to comments) |
Rating: |
Download
9.79 KiB | 885 downloads
Comments (17)
I have a problem with gfx.
Is there a specific setting needed?
Ty
During moderation I made some edits:
- Added defines for two behaviors that the sprite removed from the original pipes (to make it solid from the sides and from the top).
- Fixed a missed SA-1 converted address and added the SA-1 tag since it seems to work fine with SA-1.
- Added the unpatch file from the original pipe sprite to remove the hijack that it applies (to use if you insert the sprite and then decide to remove it from your hack).
- Fixed a bug where you could teleport while dying (which didn't break anything but it looked pretty funky).
- Some very minor code optimizations.
There's still some issues (but they are also present in the original pipe sprite):
- Yoshi's graphics don't appear while teleporting.
- Teleporting in a level where horizontal scrolling is disabled (through the level header) will cause a softlock. So, avoid using this (or the Carryable Pipes) in such levels!
- Carrying it through pipes will turn it into a P-Switch. Using this patch should fix this.
I second this but of course non-ASM beggars such as myself can't be choosers. Very cool sprite as is though.
If you install HP patches, also damage the player.
Do you mean it soft locks the player inside a wall or something, or the game actually freezes and ignores inputs? Because turn blocks on their own already have the potential to soft lock players into walls with clipping, but hard locking the player's controls is a problem. I can test it later myself, just curious what happened.