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.
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.
This issue was flagged when and effect
UIEffectwas usingdemosys.effects.textas 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(*_DIRSpaths), 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.