Be able to define the order of the addressables rules

[MightyCreak]

Hi!

From what I understand, it seems that the rules are applied from top to bottom, and if an asset is included in one addressables group, it can't be added in the next one even if the rule allows it.

Right now, the groups are ordered by their GUID, so the workaround that we found is to open the .asset file and change the GUID directly. This is the only way we found to control the order of the rules.

Is there a feature we didn't see? Or would it be possible to add a feature that would allow us to define the order of the rules?

Thank you!

[CeejayZSmith]

Although a little tedious, a work around you could try is using a CompositeLayoutRuleData. You can split your rules into multiple LayoutRuleData and add them to the composite. These should be ran in the order of the list on the composite

[MightyCreak]

@CeejayZSmith the issue is that the CompositeLayoutRuleData feature is not released yet, and apparently it's not finished either, because we synced to the latest code and we can't see the CompositeLayoutRuleData.asset in the editor... or maybe it should be done differently, but since there is no documentation, it's difficult to understand how it should be used 😅

[Haruma-K]

@MightyCreak

Sorry for the late reply!

Due to the specifications of the Addressables asset system, a single asset cannot belong to multiple Addressables groups.
Therefore, if you create rules like this, Smart Addresser will issue a warning or an error.
You should configure your rules so that each asset matches only one rule.

Does this answer your question?

[MightyCreak]

Thanks for replying!

So yes, indeed, we can't have multiple assets in the same addressables group. But, as a matter of fact, having overlapping rules in SmartAddresser does work.

From what we gathered, if we have assets in common between rule A and rule B, then when we run rule A then rule B (in this order), the group resulting from rule A will have all the assets matching rule A, and the group resulting from rule B will have all the assets matching rule B, minus the common assets between A and B.

So, as a result, the resulting addressables groups will not have any asset in common (even though the underlying rules are overlapping).

And as you can see, the order of the rules is important here. That's why we are using a workaround and we edit the GUIDs of the SmartAddresser rules (directly in the .asset file) so that the rules are displayed in the order we want. And that's why I created this issue to see if it would be possible to explicitly set the order of the rules.