plethora icon indicating copy to clipboard operation
plethora copied to clipboard

Configuration settings implemented into default settings API.

Open sorucoder opened this issue 5 years ago • 6 comments

Have configuration settings loaded in to settings API. For example, an author can use this to find out the current range of the block scanner without having to ask the player:

local scannerRange = settings.get("plethora.scanRadius")
local scannerWidth = scannerRange * 2 + 1

local manipulator = peripheral.find("manipulator")

local pos = vector.new(1, -5, 2)
local blocks = manipulator.scan()
print(blocks[scannerWidth ^ 2 * (pos.x + scannerRange) + scannerWidth * (pos.y + scannerRange) + (pos.z + scannerRange) + 1].name)

sorucoder avatar Nov 09 '18 06:11 sorucoder

I'm in two minds about this: I can definitely see why getting the range would be useful, I'm just not sure the settings API is the best way to expose it. As changing a single key will cause all settings to be saved to disk, it's not really suitable for values which may change.

It would be possible to add various getter methods for the scan/sense radius, maximum potency on lasers and kinetic augment, though that could end up being a tad verbose. I'll have a think about it.

In the case of scanner radius, it should be possible to get the width from (#blocks)^(1/3), though I haven't tested that.

SquidDev avatar Nov 09 '18 08:11 SquidDev

SquidDev said:

In the case of scanner radius, it should be possible to get the width from (#blocks)^(1/3), though I haven't tested that.

I realized that shortly after posting, but then I figured that it would be nice to access the scan range BEFORE using the scan() method.

SquidDev said:

It would be possible to add various getter methods for the scan/sense radius, maximum potency on lasers and kinetic augment, though that could end up being a tad verbose. I'll have a think about it.

I also feel that having getters and setters would clutter the existing API. And to create a custom settings function for Plethora would be nothing short of re-inventing the wheel.

SquidDev said:

As changing a single key will cause all settings to be saved to disk, it's not really suitable for values which may change.

Then maybe this should be a change to the settings API pushed to CCTweaks, as I often use alongside Plethora. But maintain compatibility with the PR release of ComputerCraft. I know if I'm going to push for this change, I'll have to post the issue on the corresponding repo, but I digress.

sorucoder avatar Nov 10 '18 00:11 sorucoder

Then maybe this should be a change to the settings API

There's definitely improvements which could be made to it with regards to saving things. However, the settings API is mostly designed for computer-specific, user-configurable configuration. It's really not suitable for reading server configs.

SquidDev avatar Nov 10 '18 00:11 SquidDev

SquidDev said:

There's definitely improvements which could be made to it with regards to saving things. However, the settings API is mostly designed for computer-specific, user-configurable configuration. It's really not suitable for reading server configs.

Oh yeah. Then how about a global table like _PLETHORA_SETTINGS?

sorucoder avatar Nov 10 '18 00:11 sorucoder

Oh yeah. Then how about a global table like _PLETHORA_SETTINGS?

That's sadly not possible with CC's API. I could probably register a custom API which just provides getters for config options, but that's a tad ugly too.

SquidDev avatar Nov 10 '18 01:11 SquidDev

Well, we could have a single method moduleConfig(key) add to org.squiddev.plethora.api.module.IModuleContainer.

sorucoder avatar Nov 10 '18 01:11 sorucoder