by MartinHowe » Tue Aug 30, 2005 11:08 am
Graf Zahl wrote:Stock monsters use hard coded melee functions and don't have any MeleeDamage property. But it still should be initialized to 0.
Furthermore, MeleeDamage is not a real property and does not get inherited at all. The same is true for all properties regarding the basic attack functions and A_Explode.
Right, so the problem is caused by overriding the attack function with one that needs an explicit MeleeDamage. Fair enough, but I would argue that there should not be a default; rather, I would suggest that this means that the "bug" I am actually reporting is the fact that the DECORATE logic does not abort with an error if MeleeDamage is not defined for a monster that uses an attack which requires it.
I guess that ideally, MeleeDamage should become an actual property of stock monsters and initialised to the damage parameter in the formula
used by their native melee damage. If no such value simplistically exists, then some value could be used that is based on, for example, how many attacks, on average, that the stock monster would take to kill a player with 100% health if the player doesn't fight back. For example, the equivalent average MeleeDamage to "pr_ettinatk.HitDice (2)".
This would probably mean a lot of extra work for Randy. On the other hand, if a programmer needs to replicate the melee damage of a "real" ettin (or whatever), that programmer still needs to know that value. Indeed, I still need to know that value for ButcheryEttin, but I've no idea what that value should be
Incidentally, what does PROP_Damage(n) do in a monster? In a_ettin.cpp it is set to 3.
[quote="Graf Zahl"]Stock monsters use hard coded melee functions and don't have any MeleeDamage property. But it still should be initialized to 0.
Furthermore, MeleeDamage is not a real property and does not get inherited at all. The same is true for all properties regarding the basic attack functions and A_Explode.[/quote]
Right, so the problem is caused by overriding the attack function with one that needs an explicit MeleeDamage. Fair enough, but I would argue that there should not be a default; rather, I would suggest that this means that the "bug" I am actually reporting is the fact that the DECORATE logic does not abort with an error if MeleeDamage is not defined for a monster that uses an attack which requires it.
I guess that ideally, MeleeDamage should become an actual property of stock monsters and initialised to the damage parameter in the formula [b]used by their native melee damage[/b]. If no such value simplistically exists, then some value could be used that is based on, for example, how many attacks, on average, that the stock monster would take to kill a player with 100% health if the player doesn't fight back. For example, the equivalent average MeleeDamage to "pr_ettinatk.HitDice (2)".
This would probably mean a lot of extra work for Randy. On the other hand, if a programmer needs to replicate the melee damage of a "real" ettin (or whatever), that programmer still needs to know that value. Indeed, I still need to know that value for ButcheryEttin, but I've no idea what that value should be :)
Incidentally, what does PROP_Damage(n) do in a monster? In a_ettin.cpp it is set to 3.