Stargate Rewritten

Stargate Rewritten

241 Downloads

[TMS TMP004] It is possible to build in an inactive gate.

Pheotis opened this issue ยท 4 comments

commented

When a normal gate is not currently activated, it is possible to build within it.
This opens up the possibility for weird behaviours and should probably be disallowed for that reason.
Notably, it is possible to use this technique to place any arbitrary block in an illegal state (i.e. place the block in the portal, remove the backing by activating the portal, destroy the portal, and keep the block in its illegal state).

image
image
image
image

commented

Fluid placement appears to be cancelled, but solid blocks work.
Dispenser + water = cancelled.
Placing bucket of water = cancelled.
Placing block = not cancelled.
Piston = not cancelled.

This behaviour appears to persist regardless of whether or not the iris is active.
Possibly related to #249

commented

This is really an issue with stupid configuration options being inherited from legacy

commented

This is really an issue with stupid configuration options being inherited from legacy

I guess the real problem then is that the migrator has no value checking when migrating old configurations. It should probably check if the value is valid for each configuration option, and otherwise set the value to whatever is default.

Or am I misunderstanding, and old configuration options are mapped to new configuration options in a way that doesn't make sense? Or is it the third case; We have config options not implemented correctly based on the legacy implementation?
Or, all of the above?

commented

Ah, it's me being unclear (as usual). So the migrator has currently copied the protectEntrance option, but this was by default false (for example the knarvik fork). So what happened here, is that the setting was expected to be true, but was false.

This configuration option can really just be replaced with our specificProtectionOverrides hidden option, making it redundant. And should also by default have protection.

I guess the real problem then is that the migrator has no value checking when migrating old configurations. It should probably check if the value is valid for each configuration option, and otherwise set the value to whatever is default.

Already done