Skip to content

Conversation

jamierocks
Copy link
Member

Only the providers that are for vanilla features have been converted, as I see no reason why any implementation would want to change the way the others are handled.
This allows CanaryLib to be implemented on Forge, and have whitelist and op working :)

Only the providers that are for vanilla features have been converted, as I see no reason why any implementation would want to change the way the others are handled.
This allows CanaryLib to be implemented on Forge, and have whitelist and op working :)
@Larry1123
Copy link
Member

Is there a working impl of this for CanaryMod?

@jamierocks
Copy link
Member Author

No.

@damagefilter
Copy link
Member

Hmm. Lets put it this way.
If you implemented a version for default canary behaviour and expanded on it to be configurable (use vanilla backend instead via config) then we have a deal.

Like CanaryDefaultThingyProvider implements ... {blah blah}

VanillaThingyProvider implements ... {blah blah}

[...]snip

Somewhere in bootstrapping:
Read Config File -> Use Custom Thingy provider?
-> Yes? -> Look for which one (for instance by specifying FQN in a config)
-> No? Use default canary provider

This way it should as well be possible to inject a default forge-specific behaviour.
Geddit? ^^

@Larry1123
Copy link
Member

That would be best. It would not force any real change in any impl using the lib.

@jamierocks
Copy link
Member Author

Is it not, just easier to move it into CanaryMod?

This seems like a lot of effort, when I can use Mixins...

@damagefilter
Copy link
Member

No because these providers pertain to the data backends which are, by default, provided by canary.
It's by design.
If there are any providers that don't use the canary backbone stuff (in hindsight, I hate that name) - these should go into the respective implementation. Absolutely.
But not the default ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants