Jump to content

Modifying Combat Arts and understanding Flags - spells.txt


Recommended Posts

  • 3 months later...

Hello:bye:

I want to improve my personal inquisitor rebalance mod and maybe make it uploadable one day. I have still a lot of ideas left that I want to implement. Currently I'm try to make a new CA: a shield buff that never reloads by default and needs to be charged manually by another CA.

Failed approaches so far:

  1. giving the CAs following tokens:
    • Shield CA: entry6 = {"et_shield_reload_rel", -1000, 0, 0, 37 },
    • Charge CA: entry2 = {"et_shield_regen", 300, 10, 0, 37 },
    • Unfortunately the shield reload does not seem to accept negative numbers and gives +496640% shield regeneration instead.
  2. changing the spellClass to "cSpellSeNotschild"
  3. using et_shieldstrength_timed
  4. using et_shieldstrength_timed and et_duration_sec at a crazy high duration
  5. mixing et_shieldstrength and et_shieldstrength_timed
  6. mixing et_shieldstrength and et_shieldstrength_timed and using et_duration_sec at a crazy high duration
  7. Changing the spellClass to "cSpellSeEnergieschild" (The SpellClass of the Golems CA "boss_golem_energieschild")

But it would be soo cool if it worked. It seems like the only way to make this work is making the shield a temporary buff and I really don't want to do that. Any ideas how I can overcome this problem? I'd appreciate any help:bow:

Edited by Lindor
Some new failed ideas
  • Like! 1
Link to comment

Btw when it comes to understanding flags I made a cool discovery:

There are multiple Tokens with crbonus_prone_xxx as a bonus. This bonus will grant vulnerability to a specified damage channel. Let's look at two of the tokens in spells.txt and their corresponding boni in spells.txt:

crbonus_prone_fire:

Spoiler

Bonus as defined in Blueprint.txt:

newBonus = {
--  name = "crbonus_prone_fir",
  rating = 2,
  basedonskill = "SKILL_INVALID",
  type = "BONUS_PRONETOCHANNEL",
  spez = "DMG_FIRE",
  spez2 = "",
  usagebits = 65535,
  minconstraints = {0,0,0},
  difficultyvaluerange0 = {0,1000,1000},
  difficultyvaluerange1 = {1,875,875},
  difficultyvaluerange2 = {2,750,750},
  difficultyvaluerange3 = {3,625,625},
  difficultyvaluerange4 = {4,500,500},
}
mgr.createBonus(54, newBonus);

Spoiler

The Token as defined in Spells.txt:

mgr.addTokenBonus( {"et_self_prone_fir", 54 })  -- 54 = crbonus_prone_fir

 

A Spell that uses this Token:

mgr.defineSpell( "dr_nm_rindenhaut", {
    eiStateName = "cSpellCast",
    fxTypeCast = "FX_DR_RINDENHAUT_C",
    fxTypeSpell = "fx_sc_schild",
    fxTypeCastSpecial = "FX_DR_CAST_L",
    duration = 20.000000,
    animType = "ANIM_TYPE_SM18",
    animTypeApproach = "ANIM_TYPE_INVALID",
    animTypeRide = "ANIM_TYPE_RIDESM01-HORSE",
    animTypeSpecial = "ANIM_TYPE_RIDESM06-SPECIAL",
    causesSpellDamage = 1,
    tokens = {
        entry0 = {"et_self_prone_fir", 200, 0, 0, 37 },
        entry1 = {"et_VWboost_rel", 100, 100, 0, 41 },
        entry2 = {"et_life_regen", 15, 15, 0, 41 },
        entry3 = {"et_base_armor_phy", 150, 100, 0, 41 },
        entry4 = {"et_base_armor_poi", 100, 70, 0, 41 },
        entry5 = {"et_armor_any_rel", 200, 50, 1, 41 },
        entry6 = {"et_VWboost_rel", 200, 50, 2, 41 },
        entry7 = {"et_chance_reflect_CC", 300, 8, 3, 41 },
        entry8 = {"et_chance_evade", 200, 2, 4, 41 },
        entry9 = {"et_life_regen", 15, 15, 5, 41 },
        entry10 = {"et_regThisBuff", 200, 2, 6, 8 },
    },
    fightDistance = 0.000000,
    aspect = "EA_DR_NATUREMAGIC",
    cooldown = 0.000000,
    soundProfile = 0,
    cost_level = 400,
    cost_base = 400,
    focus_skill_name = "skill_DR_naturemagic_focus",
    lore_skill_name = "skill_DR_naturemagic_lore",
    spellClass = "cSpellDrRindenhaut",
    spellcontroltype = "eCAtype_t_buff",
    sorting_rank = 5,
})

crbonus_prone_ice

Spoiler

Bonus as defined in Blueprint.txt:

newBonus = {
--  name = "crbonus_prone_ice",
  rating = 2,
  basedonskill = "SKILL_INVALID",
  type = "BONUS_PRONETOCHANNEL",
  spez = "DMG_ICE",
  spez2 = "",
  usagebits = 65535,
  minconstraints = {0,0,0},
  difficultyvaluerange0 = {0,1000,1000},
  difficultyvaluerange1 = {1,875,875},
  difficultyvaluerange2 = {2,750,750},
  difficultyvaluerange3 = {3,625,625},
  difficultyvaluerange4 = {4,500,500},
}
mgr.createBonus(56, newBonus);

Spoiler

The Token as defined in Spells.txt:

mgr.addTokenBonus( {"et_debuff_prone_ice", 56 })  -- 56 = crbonus_prone_ice

 

A Spell that uses this Token:

mgr.defineSpell( "he_st_kristallhaut", {
    eiStateName = "cSpellCast",
    fxTypeCast = "FX_HE_KRISTALLHAUT_C",
    fxTypeSpell = "FX_HE_KRISTALLHAUT",
    fxTypeCastSpecial = "FX_HE_CAST_L",
    duration = 10.000000,
    animType = "ANIM_TYPE_SM12",
    animTypeApproach = "ANIM_TYPE_INVALID",
    animTypeRide = "ANIM_TYPE_RIDESM01-HORSE",
    animTypeSpecial = "ANIM_TYPE_RIDESM03-SPECIAL",
    causesSpellDamage = 1,
    tokens = {
        entry0 = {"et_duration_sec", 600, 5, 0, 8 },
        entry1 = {"et_chance_reflect_spell", 200, 5, 0, 41 },
        entry2 = {"et_range_area", 750, 0, 0, 4 },
        entry3 = {"et_damping_ice", 200, 2, 0, 41 },
        entry4 = {"et_base_armor_phy", 250, 150, 0, 41 },
        entry5 = {"et_regAspect_storm", 400, 20, 0, 37 },
        entry6 = {"et_debuff_movespeed", 198, 2, 1, 42 },
        entry7 = {"et_chance_reflect_spell", 100, 3, 2, 41 },
        entry8 = {"et_debuff_prone_ice", 200, 5, 3, 42 },
        entry9 = {"et_spell_intensity_rel", 300, 10, 4, 5 },
        entry10 = {"et_regAspect_storm", 267, 13, 5, 37 },
        entry11 = {"et_damage_ice_rel", 500, 20, 6, 5 },
    },
    fightDistance = 0.000000,
    aspect = "EA_HE_STORM",
    cooldown = 0.000000,
    soundProfile = 0,
    cost_level = 350,
    cost_base = 350,
    focus_skill_name = "skill_HE_storm_focus",
    lore_skill_name = "skill_HE_storm_lore",
    spellClass = "cSpellHeKristallhaut",
    spellcontroltype = "eCAtype_t_buff",
    sorting_rank = 5,
})

Now it should be pretty clear why I chose these specific two Tokens: Both Boni are defined the exact same way in Blueprint.txt, but one Token is called "et_self_prone_fir" and the spell "et_debuff_prone_ice" suggesting that the one affects the character and the other one the enemies. And for fact Ancient Bark grants fire vulnerability to the caracter while Crystal Skin grants ice vulnerability to enemies with the correct mod. So where does that difference come from? Let's take a look at the entries:

  • entry0 = {"et_self_prone_fir", 200, 0, 0, 37 }
  • entry8 = {"et_debuff_prone_ice", 200, 5, 3, 42 }

Notice the difference at the flags? 37=32+4+1 while 42=32+8+2

Since 1 is most certainly the flag for being used in a damage calculation of a hit, I'm now pretty sure that either 8 or 2 means that it affects the enemies (or at least not the casting target). Since at the first post chattius said:

Quote

Flags:

1- If 1 then the modifier is used in damage calculation at a hit(?)

2

4 - mergeable with same modifiers from equip?

8 - done first at execution of combat art (before item stuff?)

16

32- 'lasting' effect on target, buff, temporary buff? Can be positive as reflect, or negative as damage over time ticks

64

128- base damage for spells?

 

The flags are just guesses right now.

I think we can now finally add flag two.:woot:

Edited by Lindor
A typo (rom instead from)
  • Like! 1
Link to comment
  • 1 year later...
On 10/2/2020 at 8:10 AM, Lindor said:

 

  • entry0 = {"et_self_prone_fir", 200, 0, 0, 37 }
  • entry8 = {"et_debuff_prone_ice", 200, 5, 3, 42 }

Notice the difference at the flags? 37=32+4+1 while 42=32+8+2

Since 1 is most certainly the flag for being used in a damage calculation of a hit, I'm now pretty sure that either 8 or 2 means that it affects the enemies (or at least not the casting target). Since at the first post chattius said:

I think we can now finally add flag two.:woot:

Just went over this when I've been looking into one of the changes in the PFP. The gold mod for Augmenting Guidon (Fear). It was changed into something else with this explanation in the change log:

Gold mod "Fear" was debuffing the player instead of opponents

The original definition for the fear mod is:

entry8 = {"et_debuff_EAW", 1300, 10, 5, 42 },

As you can see, it also has the flag 42, but it was apparently debuffing the player instead of the enemies. Unless it behaved strangely due to the Banner itself being a separate entity and considering the player character an enemy or something, the behavior of this mod does not seem to correspond with the 42 flag theory :/

I wonder if the mod behavior could be fixed somehow with proper flags or adjusting the blueprint definition...

Edited by idbeholdME
Link to comment
1 hour ago, idbeholdME said:

Just went over this when I've been looking into one of the changes in the PFP. The gold mod for Augmenting Guidon (Fear). It was changed into something else with this explanation in the change log:

Gold mod "Fear" was debuffing the player instead of opponents

The original definition for the fear mod is:

entry8 = {"et_debuff_EAW", 1300, 10, 5, 42 },

As you can see, it also has the flag 42, but it was apparently debuffing the player instead of the enemies. Unless it behaved strangely due to the Banner itself being a separate entity and considering the player character an enemy or something, the behavior of this mod does not seem to correspond with the 42 flag theory :/

I wonder if the mod behavior could be fixed somehow with proper flags or adjusting the blueprint definition...

Oh there you dug something up:sweating:

This is a very old thread and since last year I've learned new things, mainly from Dmitriy when it comes to flags. This thread is both amazing and very bad, it contains correct, misleading and false info, but I'd still vote for leaving it as is, it's a start from where modders can start to learn.

 

Generally: flags don't work independently, they're token dependend, spellclass dependend, whatever else dependend.

On 12/20/2020 at 3:13 AM, dimitrius154 said:
On 12/19/2020 at 10:59 PM, Flix said:

Do you have a master list of the different values for the final spell token parameter, and what they correspond to?

No such thing, since how flags are interpreted depends on specific spellClass function sets(which sometimes overlap).

37 - affects caster only.

41- affects caster and friendly units, generally.

42 - affects hostile units, sometimes buggy.

133 - affects hostile units, sometimes should be used instead of 42 to prevent spectacular glitches.

8 - affects caster once, spellclass-dependent.

9 - affects hostile once, spellclass-dependent.

On 12/19/2020 at 10:59 PM, Flix said:

"et_sacrifice_health_rel" which is functioning

Some tokens are spellclass specific, some are not tied to bonus types.

On 12/19/2020 at 10:59 PM, Flix said:

Kobold apparently fumbles a bomb or something and blows himself up.

It was to be a suicide, accompanied by a little trolling speech, but they've refrained from implementing it.

 

On 9/12/2021 at 10:36 PM, dimitrius154 said:

The attack debuff does not apply at all, if the 4th parameter is equal to 42, applies to both attacker and defender, if the 4th parameter is equal to 133.

This stuff was all prior to the FX list, learned some new things with that as well. Also something which applies to your question.

 

To your question: 

CAs have bone targets, depending on spellclass, FX used and/or EiStateName. The 4th parameter works differently depending on what is the CAs target. There are projectile spellclasses which don't have targets, like CSpellHeFeuerball, that's the one I was using for testing FX because it's compatible with all FX. If the spell requires a target using this spellclass, then you know it's coming from the FX OR it's hardcoded to the spell. With that I mean the snow storm and crystal skin, those CAs have some hardcoded properties independent on the scripting in spells.txt which messes with various testings and misleads into false test results. There might be more spells with that, so one has to be careful. Oh and BTW, bones are part of the .GR2 model.

Now after that lengthy explanation let me say this: The spell I took the et_debuff_prone_fire token from most likely is required to be cast at a target which is why with that flag it's debuffing the target while Augmenting Guidon is not cast at a target which is why it was debuffing the player. This is one instance of a parameter working differently on different spellclasses. Not saying that it is like that, but it's the explanation I imagine to be most likely.

Looking at PFP, seems like Flix simply replaced the debuff to enemies with a buff to players, seems like he's had trouble to get the appliance of debuffs to enemies to work. Maybe with the correct flags it might be possible to get it to work properly, but I don't know, SW is my second to last frequently played class right before DM. @Flix Did you try different flags here? Or you just wanted to replace it with a buff independently of the whole 4th parameter issue?

 

All in all, idbeholdME, I'd say try testing parameter 133 with super high fear value, maybe it works.:spider:

  • Like! 1
Link to comment
3 hours ago, Lindor said:

All in all, idbeholdME, I'd say try testing parameter 133 with super high fear value, maybe it works.:spider:

Thanks for the exhaustive explanations.

I am sitting on a ton of Malevolent Champion mod points, so might try to see what happens if I restore the Fear mod. Seeing whether it affects the player character should be easy by just looking at the stats.

But I'm not sure how to check for enemies. As the enemy info and their chances to hit show up only after you kill the enemy. Probably put in some insane number and just see if enemies land hits?

Link to comment
8 minutes ago, idbeholdME said:

I am sitting on a ton of Malevolent Champion mod points, so might try to see what happens if I restore the Fear mod. Seeing whether it affects the player character should be easy by just looking at the stats.

Nope. It won't work reliably. CA modifications are buggy on legacy characters. You'll have to make the modifications fisrt and afterwards create a test character.

Use this as balance.txt:

Spoiler

local newBalanceValues = {
  AdjustCriticalDamageFactor = 2000,
  AdjustDamageFactor = 1000,
  AdjustPvPFactor = 200,
  AdjustSpellFactor = 1000,
  BasepointsMultiplier = 500,
  ChanceForAdditionalSlots = 450,
  ChanceForSlotToImprove = 200,
  ChanceIncForSlotImprovePerRareLevel = 50,
  ChanceToBecomeSlotItemForBlankItem = 0,
  ChanceToBecomeSlotItemForMagicItem = 0,
  ChanceToBecomeSlotItemForNormalItem = 250,
  ChanceToBecomeSlotItemForUniqueItem = 0,
  DiceRange = 1000,
  DurationBoost = 2000,
  DurationDot = 500,
  DurationLongDebuff = 3000,
  DurationShortDebuff = 1000,
  DurationStun = 300,
  DurationPulse = 150,
  DurationStunImmunity = 450,
  EffectCombatArtChance = 4,
  EffectWeaponChance = 2,
  EffectWillpower = 25,
  KillCountBase = 15,
  KillCountInc = 2,
  LifeAttribut = 25,
  LifeBase = 130,
  LifeStep = 19,
  MaxDistLevelXP = 15,
  MinDistLevelXP = 3,
  RareBonusDanger = 1000,
  RareMalusThreshold = 150,
  RareStart = 500,
  RuneAmountTotal = 12500,
  SkillPivotPoint = 100,
  SlotGoldPercentageImprovement = 15,
  SlotSilverPercentageImprovement = 7,
  SpellBaseDamage = 25,
  TEnergyDamageRate = 600,
  TEnergyMutateChance = 500,
  ThresholdGreyXP = 150,
  TopLevelCalc = 200,
  balanceLifeRegenerationDelayCombatFac = 50,
  balanceLifeRegenerationDelayDangerFac = 1,
  balanceLifeRegenerationTime = 4500,
  balanceLevelToSkillFactor = 350,
  RegenerationFactorSkin = 800,
  RegenerationFactorArmorBase = 360,
  SpeedMin = 500,
  SpeedMax = 4500,
  SkillGroupPoints = 5,
  damBasepoints = 20,
  resBasepoints = 15,
  RangeAggro = 800,
  RangeXP = 900,
  RangeArea = 200,
  RangeNear = 45,
  AdjustConstitutionFactor = 5,
  InstantHealPortion = 500,
  ExpTeamBonus = 1333,
  ExpUpperCapPM = 125,
  ExpLowerCapPM = 850,
  ExpMinRatio = 50,
  balanceShieldRegDelayCombatFactor = 500,
  balanceShieldRegDelayDangerFactor = 2,
  balanceShieldRegTime = 2000,
  balanceShieldAbsorptionSkill = 50,
  Mounted_ondeath_healthPM = 50,
  NpcFightDamageDownScaling = 15,
  RangeAggroGrey = 100,
  KillDropMulti = 1500,
  IsUsableByHero = 700,
  TraderMaxCount = 40,
  TraderOffer_MaxLifetime = 900,
  ExpMountFactor = 1000,
  RangeClearFOW = 1200,
  LifeRegenerationDelayTime = 500,
  dropTimeItemReserved = 30,
  dropTimeItemDestroy = 60,
  dropTimeItemUnloadedDestroy = 120,
  respawnTimeStandard = 5000,
  respawnTimeMPFactor = 3,
  UpgradeStep = 1870,
  UpgradeStart = 3050,
  SwapRune_One = 125000,
  SwapRune_Two = 25000,
  SwapRune_Three = 5000,
  SwapRune_Four = 500,
  SwapRune_Foreign = 1500,
  ForgeSlot_BronceFactor = 1000,
  ForgeSlot_SilverFactor = 1250,
  ForgeSlot_GoldFactor = 1500,
  PriceAdjustment = 5,
  PriceLeveldiscount = 1,
  PriceShredder = 15,
  PriceSlotfactor = 250,
  UBmean = 500,
  UBpivot = 21600,
  UBquot_attr = 3000,
  DropQuestStart = 10,
  DropQuestQuot = 120,
  CAregenItemfactor = 500,
  RegenerationFactorArmorScaling = 1250,
  Mount_Regenburden_Warhorse = 500,
  Mount_Regenburden_Ridehorse = 300,
  RangeDistance = 525,
  RangeMidrange = 300,
  RangePickupLoot = 200,
  SpellResistFactor = 700,
  SkillAttackSpeedQuot = 5,
  SkillMoveSpeedQuot = 15,
  DurationPotionSmall = 0,
  DurationPotionMiddle = 0,
  DurationPotionBig = 0,
  ZRareExpectation15 = 1000,
  ZRareExpectation14 = 1000,
  ZRareExpectation13 = 1000,
  ZRareExpectation12 = 30,
  ZRareExpectation11 = 30,
  ZRareExpectation10 = 30,
  ZRareExpectation09 = 30,
  ZRareExpectation08 = 30,
  ZRareExpectation07 = 30,
  ZRareExpectation06 = 30,
  ZRareExpectation05 = 30,
  ZRareExpectation04 = 30,
  ZRareExpectation03 = 30,
  ZRareExpectation02 = 30,
  ZRareExpectation01 = 30,
  ZRareExpectation00 = 30,
  ZRareBasepoints15 = 1350,
  ZRareBasepoints14 = 1320,
  ZRareBasepoints13 = 1290,
  ZRareBasepoints12 = 1216,
  ZRareBasepoints11 = 1216,
  ZRareBasepoints10 = 1216,
  ZRareBasepoints09 = 1216,
  ZRareBasepoints08 = 1114,
  ZRareBasepoints07 = 1114,
  ZRareBasepoints06 = 1114,
  ZRareBasepoints05 = 1114,
  ZRareBasepoints04 = 1030,
  ZRareBasepoints03 = 1030,
  ZRareBasepoints02 = 1030,
  ZRareBasepoints01 = 1000,
  ZRareBasepoints00 = 750,
  ZRareBonusamount15 = 4,
  ZRareBonusamount14 = 4,
  ZRareBonusamount13 = 4,
  ZRareBonusamount12 = 4,
  ZRareBonusamount11 = 4,
  ZRareBonusamount10 = 4,
  ZRareBonusamount09 = 4,
  ZRareBonusamount08 = 2,
  ZRareBonusamount07 = 2,
  ZRareBonusamount06 = 2,
  ZRareBonusamount05 = 2,
  ZRareBonusamount04 = 1,
  ZRareBonusamount03 = 1,
  ZRareBonusamount02 = 1,
  ZRareBonusamount01 = 1,
  ZRareBonusamount00 = 0,
  EffectSkillChanceQuot = 5,
  RangeAggroBoss = 850,
  DamScaleIncMax = 1250,
  DamScaleRatioMin = 200,
  DamScaleRatioMax = 350,
  IsRuneForHero = 400,
  DropMaxRandomRare = 12,
  DropPowerupRare = 4,
  ExpFac0 = 110,
  ExpFac1 = 200,
  ExpFac2 = 150,
  ExpFac3 = 40,
  ExpFac4PM = 1000,
  ExpFacAdjust = 200,
  attrSdam_fact = 400,
  attrWdam_fact = 400,
  AdjustRegenFactor = 1000,
  TraderOfferUpperRareBase = 7,
  PotionHealCooldown = 700,
  UBspawn_fact = 175,
  Forge_PricePerSlot = 500,
  RuneMalusThreshold = 150,
  ExpLS100 = 985,
  ExpLS125 = 980,
  ExpLS150 = 975,
  ExpLS175 = 970,
  SkillMagicFindFactor = 400,
  NumSectors = 4183,
  PlagueImmunityFactor = 1200,
  AddOn_RegenFactor = 1500,
}
mgr.setBalanceValues(newBalanceValues);
 
--APPENDED DEFINES START
 
 
--APPENDED DEFINES END
 

local beValues = {
  NORMAL_STANDARD = 350,
  NORMAL_RUNE = 15,
  CHAMP_STANDARD = 700,
  CHAMP_RUNE = 45,
  BOSS_STANDARD = 1000,
  BOSS_RUNE = 600,
  EXTRAGOLD = 0,
  EXTRAPOTION = 0,
  EXTRARUNE = 0,
  Trader_Item = 3300,
  Trader_Many = 16000,
  Trader_SpecialOffer = 0,
  Well_Potion = 1000,
  QUEST_UNIQUE = 1000,
  SUBFAMDROP_LOWCHANCE = 10,
  SUBFAMDROP_HIGHCHANCE = 100,
}
mgr.setBalanceBase (beValues);
 
--APPENDED DEFINES START
 
 
--APPENDED DEFINES END
 


local basetables = {

  tableRows = 16,

-- begin of some hard-coded data
  EFFECTDURATION = {500,3000,5000,5000},
-- end of hard-coded data
  QuestExplow = {30,55,100,200,400},
  QuestGoldlow = {85,105,205,300,400},
  SpellFactorDiff = {800,1000,1200,1500,2000},
  QuestGoldmax = {2025,4025,8035,16040,32050},
  DefenseFactorDiff = {650,1000,1500,2500,4500},
  QuestExpmax = {4020,8250,16300,32400,64500},
  MP_experience = {1000,1150,1325,1550,1825},
  NPC_speedfac_any = {1000,1200,1300,1400,1500},
  AttackFactorDiff = {800,1000,1750,2750,4500},
  DamageFactorDiff = {1000,1050,1200,1350,1500},
  LifeFactorDiff = {1000,1400,2000,3000,4000},
  MP_damage = {1000,1050,1100,1160,1220},
  MP_lifeHP = {1000,1300,1650,2100,2650},
  MP_EShieldHP = {1000,1300,1650,2100,2650},
  MP_combatvalue = {1000,1100,1210,1330,1460},
  MP_armor = {1000,1100,1210,1330,1460},
  Spawn_OffsetLow = {0,0,40,70,110},
  Spawn_OffsetHigh = {0,100,150,200,200},
  Spawn_FactorPM = {1000,1100,1175,1250,1350},
  PriceFactor = {700,1000,1400,1900,2500},
  RuneLevel = {1,1,20,35,50},
  Potion_big_duration = {9000,9000,9000,9000,7500},
  Potion_small_duration = {9000,8000,7000,5500,4000},
  Potion_middle_duration = {9000,9000,8000,7000,6000},
  NPC_attrWdam_fact = {1000,1100,1250,1500,2000},
  MP_intensity = {1000,1100,1210,1330,1460},
  LevelCapDiff = {60,100,140,180,200},
  BlacksmithSkillForDiff = {1,20,60,105,150},
  LevelMinForDiff = {1,1,60,100,140},
  AllEnemy_lvl = {1,10,20,200,250},
  Enemy_armor = {800,900,1000,6000,7200},
  Enemy_weapondamage = {650,850,1000,3300,3630},
  Enemy_spelldamage = {500,800,1000,3500,3850},
  SpellAttackFactorMT = {1000,1330,2000,2000},
  SpellDefenseFactorMT = {1000,1750,2500,2500},
  HitFactorMT = {1000,1500,2000,2000},
  DamageFactorMT = {1000,1200,1400,1400},
  LifeQuotientMT = {2500,800,125,125},
}
mgr.setBaseTables(basetables);
 
--APPENDED DEFINES START
 
 
--APPENDED DEFINES END
 

local subfamSlots =
{
  {"SUBFAM_HORSE_SADDLE",2},
  {"SUBFAM_SEC_ARMSHIELD",3},
  {"SUBFAM_SEC_FOCUSITEM",2},
  {"SUBFAM_PRI_SWORD",3},
  {"SUBFAM_PRI_FISTWEAPON",2},
  {"SUBFAM_PRI_SHORTSWORD",3},
  {"SUBFAM_PRI_SABER",3},
  {"SUBFAM_PRI_DAGGER",2},
  {"SUBFAM_PRI_CLUB",3},
  {"SUBFAM_PRI_HAMMER",3},
  {"SUBFAM_PRI_AXE",3},
  {"SUBFAM_PRI_WHIP",2},
  {"SUBFAM_PRI_CHAINWEAPON",2},
  {"SUBFAM_PRI_BarstewardSWORD",3},
  {"SUBFAM_PRI_2H_AXE",4},
  {"SUBFAM_PRI_2H_HAMMER",4},
  {"SUBFAM_PRI_2H_SWORD",4},
  {"SUBFAM_PRI_JAVELIN",4},
  {"SUBFAM_PRI_HALBERD",4},
  {"SUBFAM_PRI_MAGESTAFF",3},
  {"SUBFAM_PRI_ENERGY_PISTOL",2},
  {"SUBFAM_PRI_ENERGY_WEAPON",3},
  {"SUBFAM_PRI_SHORTBOW",3},
  {"SUBFAM_PRI_LONGBOW",4},
  {"SUBFAM_PRI_THROW_DAGGER",2},
  {"SUBFAM_PRI_THROW_STAR",2},
  {"SUBFAM_ARMOR_HELMET",3},
  {"SUBFAM_ARMOR_SHOULDER",2},
  {"SUBFAM_ARMOR_CHEST",4},
  {"SUBFAM_ARMOR_ARM",1},
  {"SUBFAM_ARMOR_HAND",1},
  {"SUBFAM_ARMOR_LEG",1},
  {"SUBFAM_ARMOR_BOOT",1},
  {"SUBFAM_ARMOR_WINGS",2},
  {"SUBFAM_PRI_POLE",4},
  {"SUBFAM_ARMOR_BELT",4},
  {"SUBFAM_ARMOR_CLOTH_HEAD",3},
  {"SUBFAM_ARMOR_CLOTH_SHOULDER",2},
  {"SUBFAM_ARMOR_CLOTH_ARM",1},
  {"SUBFAM_ARMOR_CLOTH_CHEST",4},
  {"SUBFAM_ARMOR_CLOTH_LEG",1},
  {"SUBFAM_ARMOR_HEAD_TG",3},
  {"SUBFAM_PRI_MAGESTAFF_2H",4},
  {"SUBFAM_PRI_BLOWGUN",3},
  {"SUBFAM_MOUNT_CONTROL",2},
  {"SUBFAM_MOUNT_PROTECT",2},
  {"SUBFAM_WEAPON_BATTERY",2},
}
mgr.loadSubfamSlots(subfamSlots)
 
--APPENDED DEFINES START
 
 
--APPENDED DEFINES END
 


local subfamDroplists =
{
  {"SUBFAM_LIFE_ANIMAL",1501},
  {"SUBFAM_LIFE_ANIMAL_ATMO",1502},
  {"SUBFAM_LIFE_BARBARIAN",1503},
  {"SUBFAM_LIFE_DEMON",1504},
  {"SUBFAM_LIFE_DRAGON",1505},
  {"SUBFAM_LIFE_ENERGY",1506},
  {"SUBFAM_LIFE_HIGHELF",1507},
  {"SUBFAM_LIFE_HUMAN",1508},
  {"SUBFAM_LIFE_INSECT",1509},
  {"SUBFAM_LIFE_MECHANICAL",1510},
  {"SUBFAM_LIFE_MONSTER",1511},
  {"SUBFAM_LIFE_ORC",1512},
  {"SUBFAM_LIFE_PLANT",1513},
  {"SUBFAM_LIFE_REPTILE",1514},
  {"SUBFAM_LIFE_T_MUTATION",1515},
  {"SUBFAM_LIFE_UNDEAD",1516},
  {"SUBFAM_LIFE_DRYAD",1518},
  {"SUBFAM_TRAP_TURRET",1517},
  {"SUBFAM_TRAP_SWITCH",1517},
  {"SUBFAM_TRAP_AREA",1517},
  {"SUBFAM_TRAP_PHYSICS",1517},
}
mgr.loadSubfamDroplists(subfamDroplists)
 
--APPENDED DEFINES START
 
 
--APPENDED DEFINES END
 


local shrinkheadMinionMap =
{
    {"SUBFAM_LIFE_ANIMAL",1527,1528,1529},
    {"SUBFAM_LIFE_BARBARIAN",1562,1561,1563},
    {"SUBFAM_LIFE_DRAGON",1538,1537,1539},
    {"SUBFAM_LIFE_HIGHELF",1535,1534,1536},
    {"SUBFAM_LIFE_HUMAN",1549,1548,1550},
    {"SUBFAM_LIFE_INSECT",1588,1589,1590},
    {"SUBFAM_LIFE_MONSTER",1543,1542,1541},
    {"SUBFAM_LIFE_ORC",1558,1557,1559},
    {"SUBFAM_LIFE_T_MUTATION",1555,1554,1556},
    {"SUBFAM_LIFE_UNDEAD",1545,1544,1546},
    {"SUBFAM_LIFE_DRYAD",1552,1551,1553},

}
mgr.loadShrinkheadMinionMap(shrinkheadMinionMap)
 
--APPENDED DEFINES START
 
 
--APPENDED DEFINES END
 
 

This way you get lots of experience and high end items quickly, kinda like a self-made D3 PTR. Flix also explained somewhere in the forum how to force a specific item drop, just saying as addition on how to make test characters. if you search for "admin" in blueprint.txt, there are 3 normally undroppable cheaty items which will immensly help with damage reduction, vision range on minimap etc.

 

13 minutes ago, idbeholdME said:

But I'm not sure how to check for enemies. As the enemy info and their chances to hit show up only after you kill the enemy. Probably put in some insane number and just see if enemies land hits?

Yep. The key is the difference before and after the spell. Just make sure you don't have over 100% damage reduction or super high defense value by default. The stone throwing golems in the lava region are good for testing that because of the high attack speed.

Link to comment
2 hours ago, Lindor said:

Nope. It won't work reliably. CA modifications are buggy on legacy characters. You'll have to make the modifications fisrt and afterwards create a test character.

Use this as balance.txt:

Won't be necessary. It works with an existing character.

But the behavior is really strange. I set the values to 490,10, which means 50 at level 1. Testing with the default 42 flag.

1) Instead of reducing the enemy attack value, it makes the enemies within the banner's radius apply the effect of the Fear mod to your character on every hit. This debuff lasts somewhere in the vicinity of 10 seconds, after which it drops off. However, getting repeatedly hit refreshes the duration and adds an additional stack of attack reduction.

2) It is actually a percentage. My attack value under the influence of the banner was 352. First hit received reduces it to 176. Any additional hits further reduce the player's attack value. It also remembers how many times an enemy hit you between casts.

3) Say an enemy hit you 5 times while under the effect of the banner. The banner expires, all values return to normal etc. You then recast the banner near the same enemy, have him hit you and with the first hit, it will bring your attack value down instantly to the number as if he hit you 6 times. The game somehow keeps track of that.

So at first, it does nothing beneficial to the player and things go south the moment you receive the first hit as it gives enemies the ability to inflict the effect of the Fear mod on you with every hit, stacking repeatedly and quickly bringing your attack value to double or single digits. No idea what causes that. This has to be the weirdest behavior I have encountered in this game so far.

So what actually needs fixing is enemies applying the debuff to the player on every hit, instead of having their attack value reduced. Also not sure how the numbers behave. Testing seems to suggest it's a % reduction, but the basic values were at 1300, 1, which doesn't really make sense. I tried setting it to 9000 and even then, it was pretty much impossible for the enemies to bring the attack value to 0. Either way, it's not a flat number, otherwise it would be 0 or negative after the first hit.

 

EDIT:

Using the 133 flag makes the mod do nothing. Even with crazy values, there was no notable difference in the amount of getting hit besides the couple % from the 50 defense the level 1 banner gives. Tried an insane number and the enemies were still hitting without issues.

Edited by idbeholdME
  • Respect! 1
Link to comment

What if you change spellcontroltype to "eCAtype_a_effect_location_release"?

If that's not workying, try using spellclass "cSpellInqSeelenraub". There is hardcoded soul stuff which might tie the effect to the monster there.

If that's also not working, it's possible to duplicate the spell in spells.txt, give it another name, EiStateName and spellclass and then give it to the shadow warrior. This way we can get rid of any possible hardcoded stuff tied to the CA.

If that's not working then I don't know.

Link to comment
43 minutes ago, idbeholdME said:

So the basic behavior works correctly. What actually needs fixing is enemies applying the debuff to the player on every hit and not the targeting of the banner itself. Also not sure how the numbers behave. Testing seems to suggest it's a % reduction, but the basic values were at 1300, 1, which doesn't really make sense.

This is the effect applied:

Spoiler

newBonus = {
--  name = "sb_off_reduce_EAW",
  rating = 22,
  basedonskill = "SKILL_INVALID",
  type = "BONUS_DEBUFF_POTENTIAL",
  spez = "DEBUFF_ATTACKVALUE",
  spez2 = "",
  usagebits = 65535,
  minconstraints = {1,5,0},
  difficultyvaluerange0 = {0,35,200},
  difficultyvaluerange1 = {1,50,250},
  difficultyvaluerange2 = {2,65,300},
  difficultyvaluerange3 = {3,80,350},
  difficultyvaluerange4 = {4,100,400},
}
mgr.createBonus(668, newBonus);

It is wierd because sb_ type effects are usually for items. Maybe the issue lies there and changing it into a bb_ type effect might help.

On the line

mgr.addTokenBonus( {"et_debuff_EAW", 668 })  -- 668 = sb_off_reduce_EAW

in spells.txt, try changing 668 to 177.

Edited by Lindor
Reason: 177, not 117
  • Thanks! 1
Link to comment

Made a couple edits to the testing post. It actually does not reduce the attack value of enemies. The difference in chance to hit was from the innate defense bonus the banner gives. I later tested it without any gear to get the banner at level 1 and the enemy's chance to hit only moved 5%. When I equipped gear to reach the same defense as under the banner, the chance to hit was the same, meaning all it does is give the enemy the ability to inflict the debuff on you.

 

1 hour ago, Lindor said:

This is the effect applied:

  Hide contents

newBonus = {
--  name = "sb_off_reduce_EAW",
  rating = 22,
  basedonskill = "SKILL_INVALID",
  type = "BONUS_DEBUFF_POTENTIAL",
  spez = "DEBUFF_ATTACKVALUE",
  spez2 = "",
  usagebits = 65535,
  minconstraints = {1,5,0},
  difficultyvaluerange0 = {0,35,200},
  difficultyvaluerange1 = {1,50,250},
  difficultyvaluerange2 = {2,65,300},
  difficultyvaluerange3 = {3,80,350},
  difficultyvaluerange4 = {4,100,400},
}
mgr.createBonus(668, newBonus);

It is wierd because sb_ type effects are usually for items. Maybe the issue lies there and changing it into a bb_ type effect might help.

On the line

mgr.addTokenBonus( {"et_debuff_EAW", 668 })  -- 668 = sb_off_reduce_EAW

in spells.txt, try changing 668 to 177.

I'll try. Change both occurrences or only one?

 

EDIT:

Changed both and that MIGHT have done the trick :bounce:

The enemies now have a debuff symbol on them whenever in the banner and it seems they are hitting much less often. It does not reflect on the enemy stats section in the inventory, but the fact that they have a debuff symbol on them is a good sign. They also no longer shred the player character's attack value.

Screenshot of the debuff symbol on enemies. It showed up after changing from 668 to 177 as you suggested.

Debuffworking.thumb.jpg.3fdff060087598cbc7c0b47dbfb44a3d.jpg

 

You sir, are a genius.

But one question remains. Is it a % or a flat value reduction? Because if it's a % (which seems likely after seeing what it did when on the receiving end of the debuff), then it's extremely overpowered and the numbers need to be adjusted to a reasonable level.:4rofl:It would probably have to be tested at a very high level in Niobium, to determine with an absolute certainty.

I think it can be safely said that the intended value was 130 + 1 * CA level flat value.

Edited by idbeholdME
Link to comment

177 is flat, that's why it was changed to 668 which is percentage, to match  item modifier behaviour. You change that, then the values in all such tokens in spells.txt will need to be changed back to reflect that all CA defense debuffs will be flat reductions again. It will also be impossible to balance, since flat reductions are garbage against high level enemies and OP against weak ones. Percentage ensures smooth results.  Of course the scope of the mod is to preserve the crap vanilla balance so maybe I should have just left it alone. :sigh:

  • Like! 1
Link to comment
1 hour ago, Flix said:

177 is flat, that's why it was changed to 668 which is percentage, to match  item modifier behaviour. You change that, then the values in all such tokens in spells.txt will need to be changed back to reflect that all CA defense debuffs will be flat reductions again. It will also be impossible to balance, since flat reductions are garbage against high level enemies and OP against weak ones. Percentage ensures smooth results.  Of course the scope of the mod is to preserve the crap vanilla balance so maybe I should have just left it alone. :sigh:

I wouldn't say impossible to balance. Maybe reduce the initial value and just increase the scaling per level so that at higher levels, it maintains relevance? Instead of 130+1, make it something like a 40+4? It would smooth out the curve so that it does not completely negate enemies on Silver, would equalize at CA level 30 and from then on, have bigger impact than originally.

If it is mechanically possible to restore the original Fear mod without breaking all other attack value reductions, I think that the base functionality should be maintained if possible in the PFP (considering the goal of it).

I don't really know the exact attack values enemies have in late Niobium, but I feel that a balanced medium could be found where the reduction would not be overpowered but still had relevance in late Niob. Flat values can be insignificant, but % are the other extreme, debuffing strong enemies like bosses and champions drastically (cutting hundreds or thousands from the respective value).

But I assume it would probably mean a lot to change in the current PFP and would conflict with things like this (from the PFP change log):

  • All combat arts which debuff opponent armor, attack, or defense now do so in percentages (same as on items) rather than flat values. Fixed an issue where these debuffs were actually granting opponents the ability to debuff the player instead.

and

  • Paralyzing Dread: Gold mod "Confidence" now boosts the Inquisitor's evade chance instead of his attack (this mod was conflicting with the enemy attack debuff).

The Guidon and Dread gold mods are the only things when it comes to CAs that were outright changed in the PFP and I assume it was for the same reason. All other CA and mod changes are just fixes, QoL improvements etc.

Edited by idbeholdME
Link to comment

I think in the interests of purity I should restore the flat reductions and leave the numbers alone.  That may also allow PD's Confidence to go back to vanilla as well. Hard to say though, because vanilla PD was all kinds of broken.

Link to comment
13 hours ago, idbeholdME said:

I'll try. Change both occurrences or only one?

The first is the important one, the second is just description and is ignored in the script. I assume that has been automatically added by charon117's txt parsing programs.

13 hours ago, idbeholdME said:

Changed both and that MIGHT have done the trick :bounce:

The enemies now have a debuff symbol on them whenever in the banner and it seems they are hitting much less often. It does not reflect on the enemy stats section in the inventory, but the fact that they have a debuff symbol on them is a good sign. They also no longer shred the player character's attack value.

I have to say a couple of important things here:

Spoiler

Ok. I actually did not expect this to work. Flix told me that most of the time, sb_ and bb_ boni are the same. But there is at least this one difference

1 hour ago, Flix said:

177 is flat, that's why it was changed to 668 which is percentage

So type = "BONUS_DEBUFF", is always flat and type = "BONUS_DEBUFF_POTENTIAL", is always percentage? learned something new.

Anyway, what concerns me is the difference in the appliance. It doesn't make any sense to me unless the bonus has some hardcoded properties which makes it work differently on items. I'd say try to duplicate the sb_ bonus in blueprint.txt like this:

Spoiler

newBonus = {
--  name = "TEST123",
  rating = 0,
  basedonskill = "SKILL_INVALID",
  type = "BONUS_DEBUFF_POTENTIAL",
  spez = "DEBUFF_ATTACKVALUE",
  spez2 = "",
  usagebits = 65535,
  minconstraints = {0,0,0},
  difficultyvaluerange0 = {0,0,0},
  difficultyvaluerange1 = {1,0,0},
  difficultyvaluerange2 = {2,0,0},
  difficultyvaluerange3 = {3,0,0},
  difficultyvaluerange4 = {4,0,0},
}
mgr.createBonus(999, newBonus);

and then change the 668 token to 999 and see whether the enemies still debuff you. It would be important testing to know.

 

The effect you're seeing is the weaken effect:

http://www.sacredwiki.org/index.php/Sacred_2:Chance_for_Weaken

Also called FX_GEN_SCHWAECHUNG. These are auto-trigger FX, but why on earth should they trigger on AV debuff? Anyway, since the "Standarte" CA doesn't have any other effect applied to enemies, this means the only way the effect can be triggered is through the AV debuff which is a 100% sure sign that the fix works.

Lastly my< opinions on balance changes:

1 hour ago, Flix said:

Of course the scope of the mod is to preserve the crap vanilla balance so maybe I should have just left it alone. :sigh:

I agree here. There are not that many spells using this token, I counted 12.

I assume u did the same thing to "et_debuff_EVW"? Might consider changing that back as well, considering the potentially buggy behaviour we encountered here. We can be sure after the above testings I implied, but I think that the sb_ boni have hardcoded stuff tied to them making them behave wierdly when used on spells.:lindor:

1 hour ago, idbeholdME said:

Paralyzing Dread: Gold mod "Confidence" now boosts the Inquisitor's evade chance instead of his attack (this mod was conflicting with the enemy attack debuff).

In my opinion this is not a hindrance but an opportunity to restore and, if possible, improve the original behaviour of Paralyzing Dread's Gold mod. It's good that you noticed it.:thumbsup:

1 hour ago, idbeholdME said:

I wouldn't say impossible to balance. Maybe reduce the initial value and just increase the scaling per level so that at higher levels, it maintains relevance? Instead of 130+1, make it something like a 40+4? It would smooth out the curve so that it does not completely negate enemies on Silver, would equalize at CA level 30 and from then on, have bigger impact than originally.

Possible, but I don't think it fits the purpose of the mod. I'd just leave it at original balance if I'm allowed to give my 2 cents.:)

 

EDIT:

Also if I may ask again:

19 hours ago, Lindor said:

Did you try different flags here? Or you just wanted to replace it with a buff independently of the whole 4th parameter issue?

57 minutes ago, idbeholdME said:

Fixed an issue where these debuffs were actually granting opponents the ability to debuff the player instead.

How exatly did you attempt to fix this, @Flix? It does not seem to really work, it more looks like you replaced these boni whenever they occured on player CAs. Is that correct?

Edited by Lindor
Link to comment

The problem seems to stem from a conflict between two mods with exact opposite effects. For example percent attack boost vs. percent attack reduction.  The flat reduction doesn't conflict in the same way.  I don't think the sb_  blueprint bonus type is the issue.  There are plenty of vanilla precedents for those types being used in spells.

Paralyzing Dread was almost entirely broken in vanilla, that's why the bug was never caught before now. That mod didn't do anything.

Link to comment

Lol, second time now you answered my question before I posted it.

5 minutes ago, Flix said:

I don't think the sb_  blueprint bonus type is the issue.  There are plenty of vanilla precedents for those types being used in spells.

I want to know this now. Imma test it myself and see whether it's the conflict or the bonus. Imma post test results later.

Link to comment
37 minutes ago, Flix said:

I think in the interests of purity I should restore the flat reductions and leave the numbers alone.  That may also allow PD's Confidence to go back to vanilla as well. Hard to say though, because vanilla PD was all kinds of broken.

Agreed. If anyone would feel so inclined, it is quite easy to just change the numbers for the mod in the spells.txt.

32 minutes ago, Lindor said:

The effect you're seeing is the weaken effect:

http://www.sacredwiki.org/index.php/Sacred_2:Chance_for_Weaken

Also called FX_GEN_SCHWAECHUNG. These are auto-trigger FX, but why on earth should they trigger on AV debuff? Anyway, since the "Standarte" CA doesn't have any other effect applied to enemies, this means the only way the effect can be triggered is through the AV debuff which is a 100% sure sign that the fix works.

I think this effect is used as the "default" debuff effect for anything that does not have a specific debuff FX associated to it, which is just also used by weaken. I definitely see it often and not only when I'm under the effect of weaken.

Edited by idbeholdME
Link to comment
12 minutes ago, Lindor said:

Lol, second time now you answered my question before I posted it.

I want to know this now. Imma test it myself and see whether it's the conflict or the bonus. Imma post test results later.

The only difference between the two types of bonuses is that one has scaling values assigned and the other has all 0's. I was once concerned that the former might impart stronger values to spells, but I could find no difference between the two when used on spell tokens, all other things being equal.

Link to comment
44 minutes ago, Flix said:

The problem seems to stem from a conflict between two mods with exact opposite effects.

Nope. It's the bonus. You can clearly see by the eaken effect applied to the player character as soon as he casts standarte and an enemy hits:

GfRSbdk.png

Enemy hits without the Standarte do not apply the effect.

Interestingly, duplicating the bonus in blueprint.txt did not get rid of the problem.

Link to comment

 

40 minutes ago, Lindor said:

Nope. It's the bonus.

The difference is between "BONUS_DEBUFF_POTENTIAL", (percentage) and "BONUS_DEBUFF", (flat).  That's what I meant by conflict.  I believe your test proved it because you used the former.

 

1 hour ago, Lindor said:

How exatly did you attempt to fix this, @Flix? It does not seem to really work, it more looks like you replaced these boni whenever they occured on player CAs. Is that correct?

Incorrect.  This change was made as follows:  the final number in the spell token string must be changed from 42 to 133.  If you're not honoring that change in your tests, your results are going to be compromised.

 

EDIT:

Something that just occurred to me is that BONUS_DEBUFF_POTENTIAL might be just what it sounds like.  It simply grants the potential to the target.  That would neatly explain the behavior of enemies receiving the ability when affected, and why the final number in the string needed to be changed, and also why the problem was not apparent until switching the bonus to use "potential".  I know it's percentage rather than flat, but I never considered a basic difference in target application.   Some things I had taken on faith from older discussions might need to be reconsidered.  :B6nFRAh:

At any rate, reverting to vanilla should solve that across the board.  It's really just with the other mods I might need to reconsider the application.

Link to comment
42 minutes ago, Flix said:

The difference is between "BONUS_DEBUFF_POTENTIAL", (percentage) and "BONUS_DEBUFF", (flat).  That's what I meant by conflict.

Oh that explains it. I thought with "conflict" you meant flat value and percentage value de/increases being present in the same spell, which is the case with the standarte spell, and somehow conflicting with each other. Sry for misunderstanding.

42 minutes ago, Flix said:

I believe your test proved it because you used the former.

Correct. Would it be tied to the bonus ID, then the duplication would've gotten rid of the problem

42 minutes ago, Flix said:

Incorrect.  This change was made as follows:  the final number in the spell token string must be changed from 42 to 133.  If you're not honoring that change in your tests, your results are going to be compromised.

This was the second option and the whole reason this discussion takes place in this thread. This is what I meant with "It does not seem to really work":

Spoiler
21 hours ago, Lindor said:

All in all, idbeholdME, I'd say try testing parameter 133 with super high fear value, maybe it works.:spider:

 

16 hours ago, idbeholdME said:

Using the 133 flag makes the mod do nothing. Even with crazy values, there was no notable difference in the amount of getting hit besides the couple % from the 50 defense the level 1 banner gives. Tried an insane number and the enemies were still hitting without issues.

 

So either the test results are incorrect or the fix does not work 100% reliable.

42 minutes ago, Flix said:

Something that just occurred to me is that BONUS_DEBUFF_POTENTIAL might be just what it sounds like.  It simply grants the potential to the target.  That would neatly explain the behavior of enemies receiving the ability when affected, and why the final number in the string needed to be changed, and also why the problem was not apparent until switching the bonus to use "potential".  I know it's percentage rather than flat, but I never considered a basic difference in target application.   Some things I had taken on faith from older discussions might need to be reconsidered.  :B6nFRAh:

At any rate, reverting to vanilla should solve that across the board.  It's really just with the other mods I might need to reconsider the application.

This is a really interesting finding. Imma serve through my blueprint.txt spreadsheet and look whether I can find another bonus type that is percentage based but not affecting the  target.

EDIT: did anyone ever try to use negative values for boni? BONUS_COMBATVALUE_REL could then be used.

Edited by Lindor
Link to comment
37 minutes ago, Lindor said:

This was the second option and the whole reason this discussion takes place in this thread. This is what I meant with "It does not seem to really work":

So either the test results are incorrect or the fix does not work 100% reliable.

I tested:

  • entry8 = {"et_debuff_EAW", 1300, 10, 5, 42 }, with token bonus number 668 - Enemies applied a % debuff to the player character on hit while under the effect of the banner. This was the default behavior.

 

  • entry8 = {"et_debuff_EAW", 1300, 10, 5, 133 }, with token bonus number 668 - Seemed like it did absolutely nothing.

 

  • entry8 = {"et_debuff_EAW", 1300, 10, 5, 42 }, with token bonus number 177 - It seemed to make the enemies hit much less often, debuff symbol showed up on them. Probably the desired behavior. From reading the above, it should be flat value and not a %.

 

I did not test:

  • entry8 = {"et_debuff_EAW", 1300, 10, 5, 133 }, with token bonus number 177
Edited by idbeholdME
  • Thanks! 1
Link to comment
8 minutes ago, idbeholdME said:

I tested the 133 flag only when the token bonus number was 668.

I did not try the 133 flag when it was 177. Only the 42.

I tested it. Still doesn't do anything.

  • Thanks! 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...
Please Sign In or Sign Up