why devs commented out damagemultiplier in coombat component?

[Serpens]

does anyone know why the devs commented the following lines in combat component out?

--use nil for defaults
--self.playerdamagepercent = 1 --modifier for NPC dmg on players, only works with NO WEAPON
--self.pvp_damagemod = 1
--self.damagemultiplier = 1
--self.damagebonus = 0

 

I would like to increase the damagemultiplier in my mod.
But to do so I have to make:
 

if self.damagemultiplier==nil then
    self.damagemultiplier = 1 
end

I just want to know if I can safely do this, or if this will conflict with something?!

Edited August 12, 2016 by Serpens

[rezecib]

@Serpens When it says " --use nil for defaults", they mean that if the value there is nil, it will automatically fill in what the comment shows. So yes, you can still use damage multipliers, and you don't have to add your thing-- it's doing that already for you.

[Serpens]

10 hours ago, rezecib said:

@Serpens When it says " --use nil for defaults", they mean that if the value there is nil, it will automatically fill in what the comment shows. So yes, you can still use damage multipliers, and you don't have to add your thing-- it's doing that already for you.

Thank you for response
yes.. but in most other scripts they did not outcomment those things. So I wonder why they do it here. Yes I saw in the script they do
return basedamage * (basemultiplier or 1) * ...
But that is not a help when I want to modify the basemultiplier (==damagemultipier)

What do you mean by "it's doing that already for you?"
If I want to add, say 0.1 to damagemultiplier I cant make "nil + 0.1",  that's why I need this line that makes it 1, if it is nil. Or not?

Edited August 12, 2016 by Serpens

[Joachim]

I wonder why this is not done in a similar fashion as the external speed multipliers.

[Serpens]

yes, the external speed multiplier things are great. You can add a modchange and give it a name to safely remove it everytime you want
At the moment I try the same with combat.damagemultiplier and health.absorb, but it is difficult... Do you know a good way?

At the moment it looks like this (self.DamageHomeBonus set to nil before the function):

if tile == GLOBAL.GROUND.CARPET then
    if self.DamageHomeBonus == nil then
        self.damagemultiplier = self.damagemultiplier + GetModConfigData("damage_carpet")
        self.DamageHomeBonus = GetModConfigData("damage_carpet")
    end
elseif tile == GLOBAL.GROUND.WOODFLOOR then
    if self.DamageHomeBonus == nil then
        self.damagemultiplier = self.damagemultiplier + GetModConfigData("damage_wooden")
        self.DamageHomeBonus = GetModConfigData("damage_wooden")
    end
elseif tile == GLOBAL.GROUND.CHECKER then
    if self.DamageHomeBonus == nil then
        self.damagemultiplier = self.damagemultiplier + GetModConfigData("damage_checker")
        self.DamageHomeBonus = GetModConfigData("damage_checker")
    end
else
    if self.DamageHomeBonus ~= nil then
        self.damagemultiplier = self.damagemultiplier - self.DamageHomeBonus
        self.DamageHomeBonus = nil
    end
end

But this won't work of course, because e.g if the "damage_wooden" in modconfig is set to -1 (so for default character it would be no damage), it would get negative for characters with a lower base value of 1.

So at the moment I'm thinking of
 

-- add bonus
self.damagemultiplier = self.damagemultiplier * GetModConfigData("damage_wooden")-- of course it should not be 0, we could use 0.00001 instead...

-- remove the bonus
self.damagemultiplier = self.damagemultiplier / GetModConfigData("damage_wooden")

But what if it is 1 by default, then I multiply it with 3 and meanwhile another mod modifies it by adding +1. And now my mod removes the bonus by dividing with 3. And the other mod also removes his +1 with -1 -> (1*3+1)/3-1 = 0.3333 instead of 1...

At the moment I have no idea how to safely change this value to be compatible to other things that might change it...

edit:
The only thing that might work without problems would be modding the Combat:CalcDamage function itself, so that the whole return is multiplied with 1.1 while on a floor.

Edited August 12, 2016 by Serpens

[Joachim]

Quote

But what if it is 1 by default, then I multiply it with 3 and meanwhile another mod modifies it by adding +1. And now my mod removes the bonus by dividing with 3. And the other mod also removes his +1 with -1 -> (1*3+1)/3-1 = 0.3333 instead of 1...
 

This is why combining multiplicative modifiers with additive modifiers is evil. Hence why there are no additive speed modifiers in DST, as far as I know. It is all multiplicative, to make sure that any effect can be reversed without having to take order into account.

Edited August 12, 2016 by Joachim

[Joachim]

Quote

The only thing that might work without problems would be modding the Combat:CalcDamage function itself, so that the whole return is multiplied with 1.1 while on a floor.

Which is generally something you would like to avoid.

[Serpens]

7 minutes ago, Joachim said:

Which is generally something you would like to avoid.

is it? The only reason why I don't do this, is that I want the armor and damage bonus to be shown in tooltip mods, which uses damagemultiplier and absorb

E.g for MoistureRate I do this in my mod: http://steamcommunity.com/sharedfiles/filedetails/?id=738448215
The only side effect is, that my rainreduction bonus does not stack with the ingame rainproof concept, but this is intended, since stacking up would be much to powerful.
 

Quote

Hint:
The rainreduction from this mod does not stack up with game related rainproofness.
In the game you can wear 5 things that gives you 20% rainproofness, which will sum up to 100% rainproof.
But if you have a thing that gives you 30% rainproof and are standing on a floor with 70% rainreduction, you will receive a total rainproof of 79%.
So a rainreduction of 70% will just multiply the MoistureRate, you have after all your rainproofness bonuses, with 0.3.

 

[Joachim]

7 minutes ago, Serpens said:

is it? The only reason why I don't do this, is that I want the armor and damage bonus to be shown in tooltip mods, which uses damagemultiplier and absorb
 

 

Yes, it is best to use it as a last resort: modifying main game code directly. I know that sometimes there is no other way, but you would expect to be able to do this more elegantly than overriding a function with another function and multiplying the previous function with 1.1.

[rezecib]

1 hour ago, Serpens said:

What do you mean by "it's doing that already for you?"

If you look at where it reads from the multiplier, it has things like "(basemultiplier or 1)". So when modifying it you can do the same-- "inst.components.combat.damagemultiplier = (inst.components.combat.damagemultiplier or 1) + 0.1"

[Serpens]

11 minutes ago, rezecib said:

If you look at where it reads from the multiplier, it has things like "(basemultiplier or 1)". So when modifying it you can do the same-- "inst.components.combat.damagemultiplier = (inst.components.combat.damagemultiplier or 1) + 0.1"

yes, but in the end it would be the same result, or not?
I mean after this, the value is 1.1. And when I remove the bonus it is 1, not nil like it was previously.
If it is 1 I could set it back to nil. But I don't know for sure if it was nil before, or if any other thing changed it to 1.

All in all I think it produces ALOT confusion and uncertainties that the devs made it nil... and not just 1.

Edited August 12, 2016 by Serpens

[Joachim]

Besides, there is no guarantee that another mod doesn't set the damagemultiplier back to 1 and erases the floor bonus. Since everything accesses the same variable.

Edited August 12, 2016 by Joachim

[Serpens]

Hm.... in case of health.absorb it is even more complicated I guess.
Cause of course I can change this value. But It is also set by the game itself from time to time....
Eg. for woodie it is set to a specific value when turning into beaver. And set to 0 if transform back.
So if he would stand on floor while he transformates to beaver, my mod will reduce the value (in assumption to just remove the bonus), when leaving the floor, which will result in a false result ... =/ =/ =/

My idea would be now to mod the
Health:SetAbsorptionAmount(amount)
function, so it also calles a new introduced function from me, that corrects this.

But this won't work for combat.damagemultiplier, since there is not Set function...
But for now it seems the game does not change this value back and forth, only sets it at the character introduction...

[Joachim]

Stuff like this makes me think whether modders should not start some collaborative project to fix these things themselves, because I doubt the developers will have much time to improve on this.

[Serpens]

9 minutes ago, Joachim said:

Stuff like this makes me think whether modders should not start some collaborative project to fix these things themselves, because I doubt the developers will have much time to improve on this.

yes... rezecib's project http://steamcommunity.com/sharedfiles/filedetails/?id=741879530 does look a bit like this ^^
But I fear all of this work could be erased with one update by devs...(eg if they introduce something new/change some behaviour/functions / add functions and so on)

[Joachim]

6 minutes ago, Serpens said:

yes... rezecib's project http://steamcommunity.com/sharedfiles/filedetails/?id=741879530 does look a bit like this ^^
But I fear all of this work could be erased with one update by devs...(eg if they introduce something new/change some behaviour/functions / add functions and so on)

In a way, but his project (which I +1'ed :D) focuses on content, not so much the underlying code structure, which ideally causes the game to behave the same, only easier to change for modders.

When developers change a part of the code, and they will, we would have to create a diff with their previous code (which we used to change the mod) and their new code, so that we can see what kind of change is necessary in our version.

The problem is not so much being unable to accommodate those changes, but other modders relying on something else.

[Serpens]

hm... devs only change lua files when updating? Or is there other intern stuff they can also change, like a dll?
At the moment I think of the game "Civilization 5", there is a great modder, which released his own DLL with tons of new API functions for modders. So if you want to play with a mod that uses the new stuff, you have to use his DLL of course.

Someone could do a simular thing with DST. So all mods that uses stuff from this, throw an error message, if this "API mod" is not active.
But as you mentioned:
1) it has to be compatible to all mods that do not use this new API stuff (which might be complicated as stated above with the damge and absorb example)
2) it has to be updated for every update the devs make

I'm neither experienced, nor professional enough to do such a project...