One of the key ideas for the next OctoberProject release is fast-travel via some kind of "portal". Now, this won't be quite like Minecraft in that I don't want to create something akin to the Nether, as I have a different direction in mind for OctoberSkies, but I do still want this form of fast-travel, since a game like this shouldn't punish exploration.

There are some ideas, although non fully-baked:
-the main "portal block" could have a new aspect to bind it to a "target location"
-is the portal a single block (either base of centre) or is it an arrangement of multiple blocks (and, if so, is this the existing multi-block idea or some composite structure built manually)?
-do the portals need bidirectional bindings or can one be the target of many and lead somewhere else, entirely?
-does the target location even need to be a portal and, if so, does it break the source when broken (and how would it even know that)?
-are portals always active, once bound, or do they need to be activated in some way?

The sleazy solution I have in mind, but am not yet sold on, is:
-portals are unidirectional
-portals MUST be bound to an output portal (or nothing)
-portals are composite structures, built by the player
-internally, cuboid loading would be given a keep-alive timer and a block could request another cuboid to be loaded
-the portal block, once bound, would actually use a polling design (horrible, I know) to check if the target is a valid portal composite (thus forcing it to be loaded) every X seconds (related to keep-alive time)
-if the poll finds the target valid, it would set itself "active", if invalid, it would destroy its binding (disabling polling), and if missing would request a load of the cuboid
-when the portal is "active", the client could render some kind of effect

I am not sure if the entity should have an "enter portal" sub-action (probably) or if the portal should force their location when they intersect its active area (this is self-contained but not consistent with client-owned location so I am leaning against it).

I also wonder if this keep-alive idea can be used to simplify the per-client snapshot logic at the end of tick by moving more load/unload decisions into the CrowdProcessor. Not sure, but might be worth considering as that could eventually become a bottleneck.

Otherwise, the work to support "tool enchantments" is going well and the plans for world-gen changes are mostly solidified.

It is looking promising but I am still going to think through this portal design,
...Nights