Lag and exploit from energyToDial

[LemADEC]

As of SGCraft-2.0.4-bugfix-1, the computer interface method energyToDial has no cooldown and will actively load chunks at destination.
This can be used to scan existing stargates in the world almost instantly, see #95 .
This cause unnecessary lag and can be exploited to make a chunk loader.

I suggest to only check the list of known address without loading the target chunk, and add a cooldown as long as the dialing sequence. Adding a cache for the last call would help keeping compatibility with existing scripts.

[Bysokar]

The method isn't canon anyway.. in the show they had no idea how much power a dial would cost until they did it...
I'd suggest you put the % energy you require to dial the destination into the dialling failure for insufficient power, then deprecate the method... return 0 always or something.
Dialling time then becomes the cooldown Lem is after :)

[Dockter]

Whereas the first point is true that would completely change how the mod works so first point has zero chance of happening.

Point 2; Why don't you force a cool down in the program used to dial it vs. me forcing it server-side?

[Bysokar]

Because players can change the program theyre using.... and bypass any cooldown added.
As for the return of the dialling failure having the power requirements in the string, that wouldn't change how the mod works :D

[LemADEC]

For backward compatibility, we could have a mod configuration to disable the legacy method by default.
If everyone is ok with the deprecation, then we could ditch that method when porting to 1.15.

[Dockter]

My thoughts on this and issues.

When ciEnergyToDial is called; it needs to get the te from the dialing gate and the destination gate. The dialing system figures this out by parsing the stargate address, which will give you the chunk coordinates and the dimension id. After it knows this information it then loads the chunks TileEntityMap and searches all the tile entities in the entire chunk looking for one that is a type SGBaseTE. After it finds the FIRST one, it returns the TileEntity object. This is the only way to get the exact blockpos location of the Tile Entity which is used in the next calculation to figure out how much energy it takes to dial this location. You cannot know the exact power needed to dial the destination gate until you figure out the exact blockpos of both gates.

[Dockter]

One thought was I could change the master gate file to save the blockPOS, then use that in the math calculation instead of just "getting" the TE.