Requires<> is bogus.

[GraionDilach]

As my recent modding experiments uncovered it, Requires<> turned out to be bogus. If the required trait has multiple instances on the actual actor and the trait which is required is placed between them, Requires<> will not force the followup instances to be loaded before the trait which requires them.

Testcase in bleed TS: add AutoTarget between the two Attack* traits to the Tick Tank (ttnk). The game won't crash. Add it to the end of the unit and the game will crash due to AutoTarget is still incapable of handling more Attack* traits. AutoTarget requires AttackBase.

[RoosterDragon]

To enforce this, you just need to strengthen the rules:

This line determines which traits met their requirements. Currently if one or more dependencies are present to satisfy a dependant, that is sufficient.

You are asking for all of the dependencies to be listed before the dependant. This can be achieved with an extra condition:

var more = unresolved.Where(u => u.Dependencies.All(d =>
    resolved.Exists(r => testResolve(d, r.Type)) &&
    !unresolved.Any(u1 => testResolve(d, u1.Type)))); // This condition here.

This causes some mods to fail to load though, as they can't meet this constraint. In both cases, UpgradeManagerInfo expects all upgradable traits to be listed first, but some upgradable traits have an indirect requirement for the UpgradeManager to be defined first.

This probably indicates the existing setups for these mods are somewhat kinda buggy, but until they are fixed I'm not sure what to do about them. This indicates this issue is probably not a regression, though it is perhaps a bug.

D2k

ActorInfo("siege_tank") failed to initialize because of the following:

Unresolved:
OpenRA.Mods.Common.Traits.UpgradeManagerInfo: { OpenRA.Mods.Common.Traits.IUpgradableInfo }
OpenRA.Mods.Common.Traits.GainsExperienceInfo: { OpenRA.Mods.Common.Traits.UpgradeManagerInfo }
OpenRA.Mods.D2k.Traits.CarryableInfo: { OpenRA.Mods.Common.Traits.UpgradeManagerInfo }
OpenRA.Mods.D2k.Traits.WithDecorationCarryableInfo: { OpenRA.Mods.D2k.Traits.CarryableInfo }

due to

public class WithDecorationCarryableInfo : WithDecorationInfo { }
public class WithDecorationInfo : UpgradableTraitInfo { }
public abstract class UpgradableTraitInfo : IUpgradableInfo { }

RA

ActorInfo("pbox") failed to initialize because of the following:

Unresolved:
OpenRA.Mods.Common.Traits.UpgradeManagerInfo: { OpenRA.Mods.Common.Traits.IUpgradableInfo }
OpenRA.Mods.Common.Traits.TimedUpgradeBarInfo: { OpenRA.Mods.Common.Traits.UpgradeManagerInfo }
OpenRA.Mods.Common.Traits.AutoTargetInfo: { OpenRA.Mods.Common.Traits.AttackBaseInfo }
OpenRA.Mods.Common.Traits.RenderRangeCircleInfo: { OpenRA.Mods.Common.Traits.AttackBaseInfo }
OpenRA.Mods.Common.Traits.CargoInfo: { OpenRA.Traits.IOccupySpaceInfo, OpenRA.Mods.Common.Traits.UpgradeManagerInfo }
OpenRA.Mods.Common.Traits.AttackGarrisonedInfo: { OpenRA.Mods.Common.Traits.CargoInfo }

due to

public abstract class AttackBaseInfo : UpgradableTraitInfo { }
public abstract class UpgradableTraitInfo : IUpgradableInfo { }

[GraionDilach]

It wasn't me who claimed this being a regression but @pchote - http://logs.openra.net/?year=2016&month=03&day=09#12:14:03. In both of your example cases I'd put the blame on other traits: Cargo and Carryable requiring UpgradeManager, which is more likely to be the failure causes (although I guess D2k will break more, since all vehicles are carryable and that was just the first case.

[RoosterDragon]

I agree that the current behaviour seems like a bug - but it seems like we'll need to work out a fix for the default mods first. Something like #8848 might be needed for that though. Blugh.

[RoosterDragon]

I haven't thought this through fully, but perhaps we can resolve the circular dependency in UpgradeMananger by having it do all the required trait lookup in Created instead and removing the requires for it.

If that's feasible, that would seem to incur the least amount of work..