-
Notifications
You must be signed in to change notification settings - Fork 10
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
Implement a modifier rolling rules system #9
Comments
Possible implementation is a GlobalModifier class, where CanRoll returns false for specific item types. |
Upon further thought, many implementations are possible. Using a GlobalModifier class seems the most obvious, but alternatively we can consider attributes that can be attached to a class. However, we already have quite a few attributes to automate stuff so this might cause unnecessary bloat of them. I think what I like most, is allowing to put a specific method onto a ModItem/GlobalItem, that uses a builder-like pattern to define rules in that context. For example: public ModifierRules GetModifierRules(Item item) {
return Loot.ModifierRules.Builder()
.Accept(typeof(MyModifier)) // whitelist -type, only accept this kind
.Reject("TomsMod.Mods.HisModifier") // blacklist -type, block this kind
.Reject("TomsMod.Mods.StrongModNamespace")
.Build(); // build it
// in this example the rejects would be verbose, as the accept call turns it into a whitelist builder
} Alternatively, rulers could be separate classes to ease code separation. This would make code cleaner for modders, and myself. It allows the isolation of specific rulers, for example you can make specific rulers for themed item. Example: MyFireRuler, that ensures only fire based modifiers can be accepted on fire items. [AppliesTo(typeof(MyItem), typeof(OtherItem))] // specific items
[AppliesTo("MyMod.My.Custom.Namespace")] // all items in namespace
public class MyRuler : ModifierRuler
{
public override ModifierRules GetRules(Modifier modifier, Item item)
{
return Builder() // inherited builder helper
.Accept(typeof(MyModifier) // whitelist -type, only accept this kind
.Reject("TomsMod.Mods.HisModifier") // blacklist -type, block this kind
.Reject("TomsMod.Mods.StrongModNamespace")
.Build(); // build it
}
} To continue on the example, custom definitions could be set: [AppliesTo("MyMod.Weapons.Fire")] // all items in namespace
public class MyFireRuler : ModifierRuler
{
public override bool AppliesTo(Item item)
{
// make sure we only apply to fire items that have rolled
// a special effect: "only rolls fire modifiers"
FireItemInfo info = item.GetGlobalItem<FireItemInfo>();
return info.FireOnly;
}
public override ModifierRules GetRules(Modifier modifier, Item item)
{
return Builder()
.Accept(typeof(MyFireModifier))
.Build(); // build it
}
} As an extra, item parameter in GetRules could dyamically influence various settings: public override ModifierRules GetRules(Modifier modifier, Item item)
{
FireItemInfo info = item.GetGlobalItem<FireItemInfo>();
// if we roll "rolls only tier 1 fire modifiers"
// we only accept that type
Type modifierType = info.GetHighestTier();
// alternatively, we might want to influence 'how' the modifiers roll, not just 'what' rolls, based on item info
float rollStrength = info.GetRollStrength();
// for example: "rolls 50% stronger fire modifiers"
return Builder()
.Accept(modifierType)
.Modifies(x => x.RollStrength += rollStrength)
.Build(); // build it
} Or at least something similar, that allows one to easily identify what is accepted and what isn't. Alternatively, maybe the actual Modifier can be accepted as a parameter and the modder can filter based on that: public ModifierRules GetModifierRules(Modifier modifier, Item item) {
return typeof(modifier) != typeof(tomsModifier);
} |
Need to come up with a good implementation for this.
A GI variable?
An attribute??
hmmm.....
The text was updated successfully, but these errors were encountered: