[1.7.10] Portal as chunkloader?

[target.san]

Hi fellow modders

 

I have kind of architectural dilemma at the moment.

I may make my portals load certain chunks in vicinity, and simplify my code significantly.

Or I may not enforce this requirement, which would make my code significantly more complex.

 

I'm developing kind of better portals mod in my spare time.

One of the features I'm implementing now is transparent inventory/pipe/fluid/redstone connection through portal. The logic is, you place one of connected entities at specific position adjacent to portal frame (let's call it so), and the other on the other side, and they should be able to communicate like they're adjacent to each other.

 

This is done via tile entity methods delegation.

 

To make this thing reasonably fast, I'm caching certain TE references. Though, as you know, chunk may unload, and so all TE instances will become dead objects and subjects to GC. So I need to refresh those references, which involves not-so-trivial event handling, chunk watching and so on. I cannot use WeakReference since GC is non-deterministic.

Or, as I wrote above, I may force load chunks which contain blocks of potential interest to me, thus making TE references always valid, except cases when they're changed. As a side-effect, it would make travel a bit smoother. As a drawback, players would have some chunks being always loaded.

 

So, is it ok to make portal a permanent chunkloader or not?

 

Thanks

[target.san]

AFAIK TE isn't marked invalid when it's unloaded, only when it's actually dead. Otherwise I'd stumble upon such behavior much earlier, having my portals disassembled on each chunk unload.

 

WeakReference, as I wrote earlier, isn't deterministic due to GC. It won't get null immediately after last strong reference to object is removed.

[target.san]

Then you'll have to use the ChunkEvents instead to mark your cache invalid, but it should not be too hard, either.

That's not a problem actually. I already use own tiny chunk watcher which notifies linkers that their linked entities are unloaded

I know. But that is not why you should use a WeakReference. Imagine the following scenario:

A TileEntity that is in your cache becomes invalid because it's Block is removed. But your TE is not currently "in use" (transporting items, etc.), therefor it does not check it's cache and the (strong) reference to the invalid TE keeps it from being GC'd, which a WeakReference would not.

I've workarounded this by making my own tiny cacheable resettable wrapper. It's dropped when anything changes. Actually, each of wo linkers in a pair notifies second one that it has blocks changed around, or it's unloaded, or whatever. Then second one drops its caches, freeing TEs. Though WeakRef might really make code cleaner. Or not, since I don't always expect TE to be there. And WeakRef doesn't allow to distinguish 'null ref' from 'dead ref'.

 

Anyway, I thought a bit on a problem and decided to not enforce chunks loaded around portal. Since it's rather generic-use, and there might be many of them. Effectively exceeding per-player or per-mod chunk load limit.

 

Thanks.