For example, in the aether mod, on beta28, /setblock ~ ~ ~ the_aether:blue_portal doesn't work how it should. Reviewing the code, it isn't an error with the aether.
When using setblock, CustomPortalBlock:getPortalBase() loops forever (Although this is fixed in #17.)
After this fix however, the portal will still not teleport you, and the swirl will be the wrong color.
This could be fixed by making getPortalBase() non-static, so that classes which extend CustomPortalBlock can override and return a custom value (For example, for the aether, Blocks.GLOWSTONE).
Alternatively, you could store the portal base / dimension in the class as a variable.
However both these ideas are somewhat flawed in their current state, and there is likely a better solution out there.
For example, in the aether mod, on beta28, /setblock ~ ~ ~ the_aether:blue_portal doesn't work how it should. Reviewing the code, it isn't an error with the aether. When using setblock, CustomPortalBlock:getPortalBase() loops forever (Although this is fixed in #17.) After this fix however, the portal will still not teleport you, and the swirl will be the wrong color.
This could be fixed by making getPortalBase() non-static, so that classes which extend CustomPortalBlock can override and return a custom value (For example, for the aether, Blocks.GLOWSTONE). Alternatively, you could store the portal base / dimension in the class as a variable. However both these ideas are somewhat flawed in their current state, and there is likely a better solution out there.