Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource overriding not working properly #73

Open
einarf opened this issue Dec 31, 2018 · 0 comments
Open

Resource overriding not working properly #73

einarf opened this issue Dec 31, 2018 · 0 comments
Labels
future some time in the future.. Refactoring

Comments

@einarf
Copy link
Member

einarf commented Dec 31, 2018

In version 1.x effect package dependencies were defined as a list making it fairly easy to just pick the last occurrence if a resource if multiple resources with the same path was found. 2.x defines dependencies more in an hierarchical way making the overrides seem more or less random at times.

  • Dependencies defined in effect packages are hierarchical
  • Dependencies defined in the project file itself are still linear

This issue was flagged when and effect UIEffect was using demosys.effects.text as a dependency trying to override the default textwriter shader. I'm guessing the textwriter ends up last in the effect package list causing the system to always pick the default shader. (Flagged by @binaryf)

This raises an interesting situation: Should overrides be local for an effect package if the overriding happens in the effect package itself? Obviously we don't get these problems when only setting up a dependency list in a project because this is a linear set of data we can easily control.

Another option is to only allow overrides in FileSystemFinder (*_DIRS paths), but this would completely remove the ability to do resource overrides or local resource overrides in effect packages themselves. Maybe you have two effect packages with different overrides of the same resource?

Either greatly simplify this or come up with a user friendly way to present this to the user.

@einarf einarf added Refactoring future some time in the future.. labels Jan 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future some time in the future.. Refactoring
Projects
None yet
Development

No branches or pull requests

1 participant