Bug - Fixed Twin Peak non-combat doesn't account correctly for Cheerleader
- Thread starter Darzil
- Start date
I believe all nonstandard fairies are handled incorrectly there. Roippi and I both tried tackling that problem...
What are the nonstandard fairies? I see the following in ChoiceManager.dynamicChoiceOptions for choice 606:
So, if the familiar has a "Fairy Effectiveness" factor, you use that. Otherwise, if it isFairyType, you use 1.0.
Looking at modifiers.txt, the following familiars have "Fairy Effectiveness":
That's it. That's the only one. What other "non-standard fairies" do we see in modifiers.txt? I see some items that add fairy-ness to a familiar:
I see some familiars with "non-standard fairy" modifiers:
Looking at familiars.txt, I see that the Mutant Fire Ant, Jumpsuited Hound Dog, Steam-Powered Cheerleader, and Wizard Action Figure are all listed as "item0" - i.e. "fairy-type" familiars. The Mechanical Songbird is not, for some reason. The Baby Bugged Bugbear and Mini-Adventurer are not listed as such, but whether they are or are not is conditional.
I think the "Fairy" and "Fairy Effectiveness" modifiers are a little muddled, currently - especially since familiars with "item0" in familiars.txt don't show up with a "Fairy: 1.0" modifier, as "modtrace Fairy" will show you - although "modtrace Item Drop" will SAY that there is a "Fairy" component to that modifier.
Perhaps we should get rid of "Fairy Effectiveness" and make the Mutant Fire Ant, the only current user, simply use Fairy, and have all the item0 familiars from familiars.txt have an explicit "Fairy: 1.0". Perhaps we should rethink the familiar "type" from familiars.txt, since familiars have gotten more complicated since it was originally defined.
Code:
double eff = KoLCharacter.getCurrentModifiers().get( Modifiers.FAIRY_EFFECTIVENESS );
if ( eff == 0.0 && FamiliarDatabase.isFairyType( KoLCharacter.getFamiliar().getId() ) )
{
eff = 1.0;
}Looking at modifiers.txt, the following familiars have "Fairy Effectiveness":
Code:
Fam:Mutant Fire Ant Fairy Effectiveness: [1.3-0.15*G]
Code:
bugged bön±Ã©t Food Drop: +5, Pants Drop: +5, Candy Drop: +5, Fairy: 1.0, Equips On: "Baby Bugged Bugbear"
mint-condition magic wand Volleyball: 0.3334, Fairy: 0.3334
tiny top hat and cane Fairy: 1.0
Code:
Fam:Jumpsuited Hound Dog Fairy: 1.25, Combat Rate: [min(5,floor(W/6))]
Fam:Mechanical Songbird Fairy: [1.0+0.5*zone(Dreadsylvania)]
Fam:Mini-Adventurer ...complicated stuff...
Fam:Steam-Powered Cheerleader Fairy: [1+0.1*ceil(pref(_cheerleaderSteam)/50)]
Fam:Wizard Action Figure Volleyball: 0.3333, Fairy: 0.3333I think the "Fairy" and "Fairy Effectiveness" modifiers are a little muddled, currently - especially since familiars with "item0" in familiars.txt don't show up with a "Fairy: 1.0" modifier, as "modtrace Fairy" will show you - although "modtrace Item Drop" will SAY that there is a "Fairy" component to that modifier.
Perhaps we should get rid of "Fairy Effectiveness" and make the Mutant Fire Ant, the only current user, simply use Fairy, and have all the item0 familiars from familiars.txt have an explicit "Fairy: 1.0". Perhaps we should rethink the familiar "type" from familiars.txt, since familiars have gotten more complicated since it was originally defined.
Fairy effectiveness means that you multiply by a factor after determining its +item based on weight, rather than multiplying its weight by a factor and then determining +item. Getting rid of that would be possible but require an ugly formula somewhere.
There's also hatrack/scarecrow fairies that I think aren't properly handled.
There's also hatrack/scarecrow fairies that I think aren't properly handled.
Revision 13321 should do this. We ALMOST had the function we needed:
Modifiers.getNumericModifier( final FamiliarData fam, final String mod, final int passedWeight, final AdventureResult item )
The trick is was deciding what weight to pass in, since it wanted to pull in weight from the current item, if any, and none of the available methods on a FamiliarData would give you the weight excluding that provided by the item. I think I worked it all out and the new method:
Modifiers.getNumericModifier( final FamiliarData fam, final String mod )
should be exactly what is needed: Modifiers.getNumericModifier( KoLCharacter.getFamiliar(), "Item Drop" ) should provide the Item Drop provided by your current familiar.
Modifiers.getNumericModifier( final FamiliarData fam, final String mod, final int passedWeight, final AdventureResult item )
The trick is was deciding what weight to pass in, since it wanted to pull in weight from the current item, if any, and none of the available methods on a FamiliarData would give you the weight excluding that provided by the item. I think I worked it all out and the new method:
Modifiers.getNumericModifier( final FamiliarData fam, final String mod )
should be exactly what is needed: Modifiers.getNumericModifier( KoLCharacter.getFamiliar(), "Item Drop" ) should provide the Item Drop provided by your current familiar.