Displaying weapon special damage modification

[Kwandulin]

Hello guys,

i am currently working on a small campaign and i make use of the following weapon special that deals additional damage to trolls (and works as intended):

Code: Select all

#define WEAPON_SPECIAL_TROLLSLAYER
	[damage]
		id=trollslayer_attack
		name= _ "Trollslayer"
		description= _ "Trollslayer: This attack deals an additional +25% damage to trolls"
		[filter_defender]
			race=troll
		[/filter_defender]
		multiply=1.25
		apply_to=self
	[/damage]
#enddef

The problem is the following: Whenever it is the player's turn, the already increased damage is shown in the right column of the interface. Since the increased damage only works on trolls, the unit's damage that is displayed may easily confuse the player, if the unit attacks any other non-troll unit and deals less damage than roughly expected (Currently the interface shows: the unit's attacks are weaker if it attacks a non-troll unit. I want: the unit's attacks are stronger if it attacks a troll-unit.).

trollslayer.png

So, is there a (simple) way to show the non-modificated damage in the right column of the interface?

[zookeeper]

Sounds like a bug. I don't think I've ever had to deal with that before, so I can't really tell off the top of my head what workarounds there could be. What I would try is to add some kind of extra filter types and see if any of them cause the behavior to be flipped. Or maybe you could make the current [damage] filterless, and add another one which drops the damage back to normal against non-trolls; I'd expect the game to display the latter then.

P.S. Are you sure you're just not seeing the effects of the ToD bonus?

[Kwandulin]

I tried your second suggestion and it does work as intended now (ToD hadn't affected the unit as it was a neutral one). Thanks for the impulse!

Here is the code, if anybody is interested:

Code: Select all

#define WEAPON_SPECIAL_TROLLSLAYER
	[damage]
		id=trollslayer_attack
		name= _ "Trollslayer"
		description= _ "Trollslayer: This attack deals an additional +25% damage to trolls"
		[filter_opponent]
			#race=troll
		[/filter_opponent]
		multiply=1.25
		apply_to=self
	[/damage]
	[damage]
		name=
		description=
		[filter_opponent]
			[not]
				race=troll
			[/not]
		[/filter_opponent]
		divide=1.25
		apply_to=self
	[/damage]
#enddef

[Ravana]

Wouldnt this way manipulate actual damage? So 1.25 to trolls and 0.8 to others.

[gfgtdf]

this is a known behaviour change in 1.11.x
here is some comment about it in the code : https://github.com/wesnoth/wesnoth/blob ... s.cpp#L791.

[Kwandulin]

@Ravana: Oh, yeah, you are right. My fault. The line race=troll in the first [filter_opponent] has to be crossed out. I fix'd it in the upper comment.

@gfgtdf: Thanks for the clarification

[ChaosRider]

Here you got working special (from Random Colosseum), change special id (dwarves_tamer for your own), name, description, race for trolls race and multiply value (this with 1.5, other one is to make this special seeable all the time :]).

Spoiler:

Code: Select all

						[specials]
							[damage]
								id=dwarves_tamer
								#name= _ "dwarves tamer"
								#description= _ "Dwarves tamer:
#This attack deals 50% extra damage to dwarves."
								multiply=1.5
								apply_to=self
								[filter_opponent]
									race=dwarf
								[/filter_opponent]
							[/damage]
							[damage]
								id=dwarves_tamer
								name= _ "dwarves tamer"
								description= _ "Dwarves tamer:
This attack deals 50% extra damage to dwarves."
								multiply=1.0
							[/damage]
						[/specials]

[zookeeper]

this is a known behaviour change in 1.11.x
here is some comment about it in the code : https://github.com/wesnoth/wesnoth/blob ... s.cpp#L791.

I wonder what the exact rationale for that was, though, aside from what the comment mentions. It does result in the "wrong" behavior in cases like this, after all.

[gfgtdf]

this is a known behaviour change in 1.11.x
here is some comment about it in the code : https://github.com/wesnoth/wesnoth/blob ... s.cpp#L791.

I wonder what the exact rationale for that was, though, aside from what the comment mentions. It does result in the "wrong" behavior in cases like this, after all.

idk, maybe jamit knows more about this since he is the one who wrote that comment.