League of Extraordinary FoundryVTT Developers•2mo ago

Allowing system scope in game.settings.register

Just getting started with your type system again and trying to figure out how to get game.settings.register function to stop complaining about my system scope not being assignable to the namespace variable. Do I need to define it somewhere else?

24 Replies

Ethaks•2mo ago

The namespace has to be your system's id as per its manifest (system.json). Oh, by type system, do you mean the :typescript: types?

neckOP•2mo ago

yes

Ethaks•2mo ago

The configuration used to be something along the lines of

declare global {
  namespace ClientSettings {
    interface Values {
      "namespace.key": boolean;
    }
  }
}

declare global {
  namespace ClientSettings {
    interface Values {
      "namespace.key": boolean;
    }
  }
}

I'm not 100% sure whether that still holds true, IIRC changes to names and behaviour in this area were discussed, but the type folks would likely have more insight there.

neckOP•2mo ago

Ok, so I've got that defined within global.d.ts but (bear with me) I'm not exactly sure how to make sure the rest of the project recognises that

neckOP•2mo ago

Not sure why, but this doesn't seem to be working. I defined it in the same way as the type system itself defines it (using global.SettingConfig), but it's not picking it up anywhere

neckOP•2mo ago

also, on another note, I get a bunch of circular reference errors whenever referencing game, which is pretty annoying

Ethaks•2mo ago

I'm still using the old ClientSettings namespace in a module of mine and it seems to work just fine:

Ethaks•2mo ago

Regarding the circularity errors, @LukeAbby would have more of an overview of what errors are to be expected right now (and how to solve yours if they are not).

neckOP•2mo ago

Ok, I changed from SettingConfig back to ClientSettings.Values and that didn't solve it. Turns out the issue was that I was using template literals

Ethaks•2mo ago

Out of curiosity: what type did they resolve as? string or a constant?

neckOP•2mo ago

a constant Ok, now running into another issue wrt settings. I can't seem to reference the setting default, and I'm not sure how I'm supposed to do so anyway considering game.settings.settings seems to be a Map<string,SettingConfig> and makes no reference to the default property

LukeAbby•2mo ago

fwiw template literals will work if the source types are also constants. Yeah we have backwards compatability. SettingsConfig is the new interface Those errors look fine, probably annoying to have around, but fine. I'm hoping to squash them soon but it's the primary reason it's been stuck in beta for so long the game.settings is possibly undefined one is correct

neckOP•2mo ago

yeah, that one's fine

LukeAbby•2mo ago

the rest are just annoying errors in fvtt-types that are leaking out As for game.settings.settings it sounds like you want it to be typed more concretely?

neckOP•2mo ago

It just seems like it's not actually the correct type

LukeAbby•2mo ago

Well looking at ClientSettings it is:

class ClientSettings {
  constructor(worldSettings) {

    /**
     * A object of registered game settings for this scope
     * @type {Map<string, SettingsConfig>}
     */
    this.settings = new Map();
    ...

class ClientSettings {
  constructor(worldSettings) {

    /**
     * A object of registered game settings for this scope
     * @type {Map<string, SettingsConfig>}
     */
    this.settings = new Map();
    ...

maybe SettingsConfig hasn't been updated? what do you expect SettingsConfig to have or do that it currently doesn't oh and to be clear this is different than SettingConfig. The name overlap is annoying.

neckOP•2mo ago

In the type definitions I'm looking at you've got it set as Map<string,SettingConfig> and not Map<string,SettingsConfig> Now I'm not sure how that's supposed to work considering SettingConfig is an interface mapping settings to their data types. I think it's just a typo

LukeAbby•2mo ago

ah that'd do it haha

neckOP•2mo ago

But if I change it to Map<string,SettingsConfig> that's not correct either

LukeAbby•2mo ago

wonder when that slipped in what's broken with Map<string, SettingsConfig>? Well the keys aren't exact, it'll allow you to try any setting.

neckOP•2mo ago

The object should have schema

{
  config:boolean
  default: [DEFAULT VALUE OF UNDERLYING SETTING]
  key: string
  name: string
  namespace: string
  scope: "client"|"world"
}

{
  config:boolean
  default: [DEFAULT VALUE OF UNDERLYING SETTING]
  key: string
  name: string
  namespace: string
  scope: "client"|"world"
}

as in the object that game.settings.settings is a map of

LukeAbby•2mo ago

Had to actually open up fvtt-types yeah the issue was it was Map<string, SettingConfig> not Map<string, ClientSettings.SettingConfig>

neckOP•2mo ago

there we go! thank you

LukeAbby•2mo ago

you should be able to update your fvtt-types and it'll work I'm assuming this was just something missed when adding SettingConfig to the global scope. my fault really didn't check for shadowing rules even though I did check to see if they used the right names out of the several confusing ones I've now made it settings: Map<keyof _SettingConfigRecord & string, ClientSettings.SettingConfig>; _SettingConfigRecord basically being the global SettingConfig, i.e. the one you merged into It just exists for backwards compatability with ClientSettings.Values etc.

Gaming

Programming

Allowing system scope in game.settings.register

Did you find this page helpful?