Is your feature request related to a problem?

It is already possible to transport entities from the current location to a destination, but I want to be able to request a destination to push their entities to my location as well.

Currently, you can create a Timedoor Marker, put its location in a location card, and then put that card into a Timedoor Projector (with a buffer of chronons). On the Timedoor Projector you can give it a redstone signal to open a portal connecting a location near the projector to the marker.

This does not chunkload the other side of the portal. I tested this by going 10k blocks out in the overworld, putting a minecart next to the marker, then opening a timedoor to there from spawn: the minecart did not come through until I went through myself.

Additionally, in order to set up a two way connection between two locations, I need to set up two markers and two projectors, this can be a bit awkward to lay out properly. So suppose I already have a Timedoor Projector linked towards a marker, I could do the opposite by linking a 'Timedoor Requester' to that Timedoor Projector.

This way each outpost only consists of a marker and a requester, and my central warp zone only consists of projectors (and the only chronon production is at the central warp zone).

In my particular case, I thought it would be a cool visual to have a 'distributed factory' where portals open, items get passed in, a job completed on the other end using those items, and the resulting items get passed back through the portal. If the job takes too long, the other side could be responsible for keeping itself loaded until the job is done, then when it is done 'requesting' that same timedoor open again. Or instead of the other side keeping itself loaded, the factory side could keep the portal open / keep re-opening the portal until the results come through.

Solution(s)

• When a timedoor is opened (maybe only on markers with specific settings) it should chunkload the destination for only the period where the portal is open, and maybe load the adjacent chunks too to avoid chunk boundary jank.
• Additionally, a new block 'Timedoor Requester' can be used to ask a distant projector (or workstation) to open its timedoor. Perhaps requesting should load the projector's chunks just as a marker would, and any metronomes should be able to account for the time they spent unloaded so that they do not run out of power.

Describe alternatives you've considered

Simply having a chunkloading mod suffices for the behaviour I want. However, this request is simply to make it possible within this mod alone, and with the appropriate stylisation and restraint, e.g. chunkloading the bare minimum, having balanced resource costs, having cool visuals with the processing.

I understand that transporting non-players might be out of scope for this mod, but it seems like a more balanced and interesting way to do it than some ender-storage or inter-dimensional storage network.

Mod Version

3.0.1

Mod Loader Version

1.21.1 - 21.1.160

Mod Loader

NeoForge

Additional context

I'm intending to use this mod with the new packages from the Create mod, as they are entities that can encode the 'job' that needs doing in their address, and these entities can pass through the timedoors consistently.

Currently I have everything permanently chunkloaded, and I have two timedoors (projector from outpost to central marker, and projector from central to outpost marker) per outpost.

It does load the chunk, but does not tick the chunk. It loads the chunk enough so that if you do push an entity through the timedoor it doesnt disappear when it goes through the other side, but not enough so that the chunk is still operational and something can wander back through to the other side. I am worried about doing that for the reason that it would have an impact on performance, especially with workstations which permit a timedoor to be open indefinitely.

If you had a single hub with a bunch of timedoor projectors and markers, you'd only need 1 extra marker, maybe near the entrance, to allow travel back and forth. Given that, im not sure itd make sense to implement this feature. But i am open to feedback

If you had a single hub with a bunch of timedoor projectors and markers, you'd only need 1 extra marker, maybe near the entrance, to allow travel back and forth. Given that, im not sure itd make sense to implement this feature. But i am open to feedback

The return trip is for an item, not a person, so there is not necessarily a common 'entrance' to go to.
Also, having a projector at an outpost means that outpost must have chronon production.