The following line is causing TE's to be created nonstop and chunks to unload/load while viewing the dialing device GUI with "Dial" button on

https://github.com/McJty/RFTools/blob/1.10/src/main/java/mcjty/rftools/blocks/teleporter/TeleportationTools.java#L227

Here is a trace
https://gist.githubusercontent.com/bloodmc/7e9c8613cba02a530a936365c121543f/raw/da83a0353aa245a2c4781acf202c10b50f1c80ef/dialingdevice_trace.txt

The cause of this is due to 2 issues,

The first is with GenericWorldProvider not accounting for canDropChunk

https://github.com/McJty/RFToolsDimensions/blob/1.11/src/main/java/mcjty/rftoolsdim/dimensions/world/GenericWorldProvider.java

Every tick, the ChunkProviderServer will attempt to unload queued chunks. Before queuing a chunk for unload it checks the canDropChunk method of the WorldProvider, such as WorldProviderSurace, if the chunk can be unloaded. GenericWorldProvider doesn't override this so it falls back to WorldProvider logic which simply returns true always. This causes the constant chunk reloads.

The second is with DimensionType registration not setting shouldLoadSpawn to true OR the MatterReceiver TE keeping the chunk loaded to avoid reloads.

On Sponge's end this breaks the dialer as a TE will not be returned for unloaded chunks. However if the above is fixed, sponge will work correctly.

Hmm. I don't think it is right. The implementations of the nether/end canDropChunk also return true all the time just like RFTools Dimensions do. This is only meant to return false for spawn chunks otherwise chunks will never get reloaded.

Also the second comment is not right either. The fact that the matter receiver is at 0,0,0 is a detail. The player can just as well move that receiver to another chunk.

So rftools dimensions should not keep any chunks loaded. That's not how this is supposed to work.

Note that matter receivers can be placed anywhere. They are generated automatically at spawn chunks in rftools dimensions but players can put them at any chunk in any dimension.

So not sure what there is to fix but your suggestions are not right as far as I can see

Also:

'On Sponge's end this breaks the dialer as a TE will not be returned for unloaded chunks. However if the above is fixed, sponge will work correctly.'

That's going to break a lot of mods... Why change that behaviour? RFTools depends on that at many places.

"The second is with DimensionType registration not setting shouldLoadSpawn to true OR the MatterReceiver TE not keeping the chunk loaded to avoid reloads."

The latter part should of been KEEP the chunk loaded to avoid reloads. If the player can move the receiver then the receiver should keep the chunk loaded or you will have the situation I mentioned above where a player can just sit at the dialer and cause TE's to be recreated as well as chunks to unload/load until they TP to the location(assuming no other player exists there).

You could also just keep the chunk loaded as long as the dialer is active/searching. This might be a better solution depending on the number of receivers out there to avoid too many chunks loaded. So a player activates a dialer, force the chunk to be loaded until that dialer is deactivated.

Sponge avoids returning TE's for unloaded chunks to prevent this very issue with mods causing TE's to be recreated nonstop as well as chunks to reload constantly which impacts performance on servers.

Update: I moved some logic around to help avoid constant chunk reloads and will allow TE's to be retrieved again regardless of chunk load status. I also have a bunch of SpongeForge fixes that will be pushed soon to fix the remaining RFTools issues. However, RFTools still manages to load the same chunks every few ticks so a fix should also be done on your side as stated above.

I do plan to revise how the dialer checks for this in any case (perhaps don't check as often or something) so it is good that you brought this up in any case