Lindor

Well I know what you mean now. But I don't see anything where something like this is scripted. From what I thought, it's the same behaviour as "enemy walks out of range": I thought if the current section of the animation has already triggered execution, the range is infinite and you only have to walk into distance again when the next section of the animation is reached. That's how I always explained this to me. Like the animation is split into sections and you only have to walk into fightdistance at the start of each section. Don't know what exactly determines the start/end of a section though. It might also be that the range is not infinite and really depends on enemy size, but I haven't noticed that before.

Usually the range is dependent on the weapon used, more specifically the "fightdistance" entry in typification.txt for the classification of the itemtype in itemtype.txt which used for the weapon's blueprint in blueprint.txt. Moreover, if an enemy walks out of range after the animation started executing, it still hits. So it's not really "fightdistance", it's more like "minimum range for starting the animation execution". All in all, I'd say it's not dependent on the CA in spells.txt. So I don't see why the range would be any different than from other close combat CAs.

The classification system is up and running, both for weapon and armor. I made it so that it's looked at weargroup and modelname for armor itemtypes to get the standard armor set of the itemtype, and it's looked for both blueprint name and itemtype subfam and only if both classifications match, the itemtype is classified. There is a warning displayed if they don't match. Btw the Itemtype-Weargroup-Relation works by looking both at itemtype and model weargroup. It's a complicated logic, and I think it's very stable. This system is hereby deprecated (the armor set classification is still used though). However I got some useful information out of it: The armors match their purpose for all heroes very rarely. Chaos like this is the most common: name = "hero_chest_strap_fight_rare", classificationbits = "2343152", So for an armor set, if it is e.g. Aspect one for Seraphim, one can guarantee that the same armor set has a completely different purpose for another hero. like e.g. the same item is part of scourge set of inquisitor which is aspect three and part of angeldust set of seraphim which is aspect one. If it's just aspects it would be kinda okay, but there are also items which are spell for one hero and melee for another. This is very bad because, in case you decide to go with the usagebits-option and not make every item single itemtype, I can't give the armorsets useful boni based on their purpose like that. So if you use usagebits, pretty much every armor with automated bonusgroup generation will either have the ability to spawn every bonus available for the hero on armors, or only general-purpose boni like defensive stuff, depending on your settings in balance.lua. @dimitrius154@FlixIs it possible to get the hero you're currently playing and load this information into blueprint.txt before blueprint.txt is being executed during the server loading stage? If so, I can solve the problem.

This may be a wierd question, but "MB_highelf_combomaster_staff"'s itemtype is classified as "CLF_POLE". Is this correct or should it be wizzardstaff?

There are some interesting SUBFAM's which are unused in itemtype.txt: "SUBFAM_PRI_CHAINWEAPON" "SUBFAM_PRI_FOIL" "SUBFAM_PRI_WHIP" "SUBFAM_ARMOR_BATTERY" Especially the whip is interesting: there exist two itemtypes which use it, but the itemtypes are unused in blueprint.txt. They even have models already. I'm considering reviving some of those. Maybe it's something for EE as well.

I love your ability to always find something good even in the worst crisis. Covid is like the worst, it can tear families and whole societies apart. Your positivity gives hope to everyone who's facing this threat, including myself. Wish you and your family the best!

Wait what do the classifications have tod do with bonusgroups? Do you mean like, if it's CLF_DEFAULT, the correct classification is derived by bonusgroups? If that is so, I wasn't aware of that. I plan a hybrid classification system for weapons: As first instance, it is looked for certain strings present in the item name, like "pole" or "bow" e.g. This half is already completed. If that's inconclusive, it is looked at the Families and Subfamilies of the itemtype. This half is not yet completed. Theoretically I could advance this system into an automated classifications system. Classifications can always be derived from these three parameters I hope? I have all the possible classifications from the .dll data dump thread. EDIT: Oh I see it's done through typification.txt. With this data, I can correct the classification automatically upon running Enable.exe. EDIT2: Wait you mean the bonusgroup being called by the classification, not the classification being called by the bonusgroup right? Well that's easy to fix then, just change all bonusgroup IDs in typification.txt to 0 upon enabling. When such an amount of confusion happens, it's time to go to sleep. Good night

I managed to solve the problem! The solution is again: linear interpolation! Here's how it works: I implemented scaling with item tier directly in balance.lua: These are the values used for ALL bonusgroups, the balance is kept via manipulation of difficultyvaluerange. For each difficulty, the extracted linear bonusstrength function of the item tier is multiplied with the old difficultyvaluerange to get the desired funtion. Then I modify the difficultyvaluerange so that, when I multiply it with the new linear bonusstrength function of item tier as set in balance.lua and afterwards add the difference between these two function for all item tiers to get the total amount of error, this error equals zero. The end result may be a little bit too high/low for low item tiers and too low/high for high item tiers, but the average is the same as the old mod's balance. I'd even argue that it improves the balance as it keeps consistency. And it gives the modder the ability to modify scaling with item tier for all boni with a single number change! Here's a little snippet of the end result for EE with above settings for bonusstrength:

If I apply this idea, this happens: Ridiculous numbers. Additionally comes the problem that bonusstrength at the blueprint's bonusgroup applies to the whole bonusgroup, making different difficultyvalueranges mandatory. I will not apply a normalized difficultyvaluerange, instead I will apply a normalized bonusstrength and change the difficultyvaluerange at the bonus for keeping the balance. As a side note: I have no idea why the BONUS_ADDCA_HORSE balance first in- and then decreases. It should be a linear function. EDIT: I know what happened. It was a bug in the code. Nevertheless the problem with the strength applying for all boni in the bonusgroup still holds true, which is why I'll go with the normalized bonusstrength idea. EDIT2: I just realized that if I did this, I'd sacrifice bonus scaling with item tier. It's the way the system works: Either have scaling with tier or have correct values or have only single bonus bonusgroups. I don't know if and how this is resolvable. Uhmmm... help?

I really shouldn't be awake this late, but you know me Spent whole night to achieve this for items: The two values are the slope and the y-intercept of the interpolated linear function of the data set of all the (item tier - bonus value) pairs for each bonustype EDIT: As full list of bonus strengths for item tiers 0-15 it looks like this: As extracted from EE

The classification conflict happens indeed quite often even within single weargroup items. E.G.: "hero_wings_technic_normal" has two "leather" itemtypes which I classified as "ranged" and one "special" itemtype which I classified as "generic".

There we go: The classificationbits are in same order as usagebits. They're NOT converted into decimal, so each digit stands for a hero. This is what the digits mean: local classificationOrder = { AspectOne = 0, AspectTwo = 1, AspectThree = 2, Generic = 3, Melee = 4, Ranged = 5, Spell = 6, } Only issue is when one armor has multiple itemtypes with different classifications for the same hero. It's possible to set in balance.lua that each item is created once for each itemtype and disable usagebits though (it's either usagebits or once for each itemtype). I may consider to implement classification directly at the main logic in blueprint.txt. If you choose to use the single itemtype option, then the classification conflict will get solved as well.

Aaaand Done! Only need to implement the flags system, and all the pieces necessary for the automated bonusgroup generation are there. As far as I can tell, there are 2024 distinct single hero weargroup itemtypes for non-set/unique/legendary armor. @gogoblender Is it okay if I keep you informed of the progress here? I know other forums where this might be seen as spam.

According to Dmitriy, the four Wounds effects don't work as item modifier.

I have completed but not finished the Standard Armor Set classification: The classification is, other than the Aspect and Mutation Set Classification, completely subjective. I just looked at the armor and thought "oh that looks like ranged". Can be modified later by modders. I plan to extract the data from the model name used in itemtype.txt, and then add the flag to each item which uses this specific itemtype. Because flag-conflict might occur, I thought about a usagebits-style flag, but with base 7 and not base 2.

Oh this is so bad. Then it's not even defined for the bonus, but for the CA (and I'm guessing each individual item?). How can anyone ever come up with such a spaghetti idea? Anyway, there's no way anymore to keep the balance for me then. I'm just gonna go with the closest I can do which is to pretend it'd work like the pseudocode above, and accept that it'll change balance. @Flix and @all other interested modders, hope you can live with that.

I know this thread is old, but Exactly what I was looking for! Quote wiki: "The Battery projectile's damage consists only of damage listed upon the battery itself, and it will be enhanced by any appropriate modifiers from skills (such as Tactics Lore), attributes, and equipped armor." Unfortunately it isn't stated which weapon lore influences the battery. The battery attack has a spell defined in spells.txt, "tenergy-gun_tg", with spellclass "cSpellProjectile". There you can also confirm that it's influenced by tactics lore and doesn't cause spell dmg. How has this been confirmed? As Dmitriy found out, Attack Value and Defense Value don't play any role in non-Addendum versions of the game.

So (pseudocode) it's like: funtion apply(difficultyvaluerange, bonusstrength) if difficultyvaluerange == 0 then do return bonusstrength end else local newbonusstrength = (difficultyvaluerange / 100) * bonusstrength do return newbonusstrength end end end ?

Hmmm my idea would be: for each instance of a bonus used, e.g. for each token of each spell in spells.txt, I'm gonna backtrace to the bonus in blueprint.txt, then multiply the bonus strength of the spell token with the highest difficultyvaluerange value of the bonus, divide it by the new highest difficultyvaluerange value, e.g. 100 if I use above normalization, round it to the next integer and then overwrite the old value with the new one. So instead of saving the usage value for each bonus, I apply it directly at the bonus usage in the game's txt scripts. You think this can work? EDIT: Oh there's a problem. Some difficultyvalueranges equal 0. I'm guessing it works as Bonus * (1 + difficultyvaluerange) then? And the numbers, are they percentage or per mille?

Oh boy the Sacred 2 code is just pure spaghetti. The devs invented so many different functions which practically do the same thing, just look at weargroups or bonusstrength. The thing I'm worried about in particular atm is difficultyvluerange. I already have the bonus classification and basedonskill.lua, I don't want to create yet another module for modifying boni. Generally sorting is there to increase the overview, like the sorting of the different itemclasses where e.g. each jewelry item is listed in the same file and there's a file for each itemclass, but here having three or more modules for each bonus is overkill and ripping it apart, not sorting. I'm thinking about normalizing difficultyvaluerange for each bonus. Something like: difficultyvaluerange0 = {0,10,20}, difficultyvaluerange1 = {1,20,40}, difficultyvaluerange2 = {2,30,60}, difficultyvaluerange3 = {3,40,80}, difficultyvaluerange4 = {4,50,100}, or so. The exact values can be modified in balance.lua then. The downside is that the modders would need to revisit the bonusstrength pretty much everywhere. The other extreme would be extracing and saving each value for each bonus, the values get averaged if there are multiple instances of the same bonus. A middle way would be interpolating the values into a linear function with constant spread per difficulty, then for each bonus only three values, namely f(0), slope and spread, would need to be saved. While it would save memory space and loadtime, at the same time it would probably be a little confusing for modders. Last but not least, I could also go with option 1 but automatically adjust the bonusstrength everywhere upon running Enable.exe. It would be lots of work though and I can't guarantee that the balance is completely unaffected, but imho it's the best option so far. Also it would need to be necessary to implement the bonusstrength correction into the Update.exe, so that everytime you change the normalized difficultyvaluerange in balance.lua, it doesn't affect total strength and just affects scaling. @Flix @dimitrius154 What do you think? I'd be interested to hear your opinions about this.

That's not how it works. I have written the formula above. For your exampe it would be (0.1*0.9+0.9)/(0.1*0.9+1)~90.82%. Has nothing to do with being a portion of your missing SB. Why can that safely be said though? It was so in Sacred Underworld, but why in Sacred 2? Usually chars with high SB also have high map reveal, unless you let your char stand in bronze near an enemy close to the starting area for 500 hrs to farm SB. Or is there some sort of character editing which can set your map reveal to zero? I know that SB is allergic to modding, even Dmitriy couldn't do anything here and that says something. I'm not sure wether any amount of reverse engineering will ever be able to answer your question. Nevertheless it's worth a try.

Okay first of all I want to clear with the myth that "Faster increase of survival bonus"(pre CM) / "Survival Bonus" (post CM) would directly increase your survival bonus. It's not true. It directly multiplies your ingame combat time by (1+B) where B is your item modifier bonus. Since the Survival bonus formula is S=T/(T+6) where T is ou combat time in hours, we can calculate that the formula for how this modifier works is: S_2=(BS+S)/(BS+1) where S is your Survival bonus without the modifier, S_2 is your Survival Bonus with the modifier and B is the modifier bonus. So that's the second time this obscure bonus has been demytified now. Why is this important? You can directly see the impact your Survival bonus has on CtfV by equipping an item which has this as a modifier. All instances of CtfV are added together, so if you're clicking on the Sigma sign in the character's inventory, get your total CtfV from there and then subtract all instances of CtfV from your gear from that, you have the exact amount of CtfV your Survival bonus gives you. Now when equipping an item with the "Suvival Bonus" modifier one would think that this would also increase your CtfV by the formula above? Haha no. The "Survival bonus" modifier has absolutely zero impact on your CtfV, only the hard Survival bonus counts. To me it seems like the "Survival bonus" modifier only has an impact on your character Attributes. Honestly I think that the displayed survival bonus in your inventory is a scam, the "Survival Bonus" modifier has zero impact on your Survival Bonus and just multiplies your attributes by above formula. I will edit the wiki page of this bonus to give that information. (EDIT: Done) Okay now for real, why is this important? If you want to make a test series on your CtfV you get from characters with different survival boni, you can send me your data and I will see wether I can derive a formula. BUT: It is important that you have no "Survival bonus" modifying item equipped and only notify the clean survival bonus. EDIT: Forget what I said, accidentally divided %map revealed by 8 instead of 4, resulting in me believing the difference would come from the Survival Bonus.. The Survival Bonus chance to find valuables is not visible in the inventory as far as I can tell. The part for the Survival Bonus item modifier formula however is correct, though that doesn't answer your question.

Update: I have just finished scripting the bonus name&ID generation module. It dynamically transforms above bonus classification and the list into smth which looks like this (snippet): (......) bb$BONUS_DISARM$$ = 55, bb$BONUS_PIERCING$$ = 56, sb$BONUS_PIERCING$$ = 57, bb$BONUS_SHRINKHEAD_DROPCHANCE$$ = 58, bb$BONUS_WOUNDEDRAGE$$ = 59, sb$BONUS_WOUNDEDRAGE$$ = 60, bb$BONUS_WEAPONDAMAGE_REL$DMG_FIRE$ = 61, bb$BONUS_WEAPONDAMAGE_REL$DMG_FIRE$SUBFAM_LIFE_ANIMAL = 62, bb$BONUS_WEAPONDAMAGE_REL$DMG_FIRE$SUBFAM_LIFE_ANIMAL_ATMO = 63, (.....) it loads all possible boni in a random order and assigns it IDs, skipping all hardcoded bonus IDs. As currently, there are 1576 possible different boni and 2 hardcoded boni (bb_charge_morph_duration, crbonus_faction_modifier_enemy_hero). Not sure wther I wanna keep dollar signs as separator or use something which "sticks out more" to the eye, but that's just an aesthetic question and the bonis ID/name correlation list won't be something where modders will look into as it's generated automatically every time you run Update.exe. ------ I'm repeating myself because that's kinda a core question, and I'm not sure how to test it ingame. I'd need a bonus where it's absolutely sure that it only works for spell damage and nothing else, and I'd need the same for ranged and melee, and something like this doesn't exist yet. And even if it existed, it would still not satisfy the question because it could still be handled as something completely separate, like hybrid dmg based combat arts.

Oh that is beautiful!

Looking forward to what you come up with xD