Color Changes and Status
Moderator: Forum Moderators
Color Changes and Status
Where exactly is the code that causes a unit with status poisoned=yes to turn green and display the little green skull icon? Or to make a unit translucent when it has status hidden=yes? I'm trying to make a weapon special that has a slightly different effect on HP and turns the unit red instead of green, but I can't figure out where to write the code to do that. If someone could just tell me the file that it's in, I can work it out from there. (I'm assuming it's not going to be in WML; am I wrong? I didn't think it could be that easy, or I would have already figured it out.)
Thanks!
Thanks!
"Don't you worry about cancer?"
"I AM cancer. I do not frighten myself."
"I AM cancer. I do not frighten myself."
Moved to WML workshop.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Moved to a more appropriate place
Actually this is not doable in WML and the question was probably more about the C++ code.
The information you're looking or is probably in generate_report.cpp & unit_display.cpp .
Actually this is not doable in WML and the question was probably more about the C++ code.
The information you're looking or is probably in generate_report.cpp & unit_display.cpp .
"Ooh, man, my mage had a 30% chance to miss, but he still managed to hit! Awesome!" -- xtifr
Erm, it depends.
If you use the following WML code, your unit can be turned to red as if it was hurt. The effect is the same as if it was normally attacked:
I think [unstore_unit] supports opacity set too (alpha value), but I'm not completely sure about this because I haven't seen it in action, unlike the code above (used a lot in UtBS and IftU).
The only task left would be to make it in an "name=attack_hits" event that filters on attacker's weapon name (special unit filter). Although it doesn't filter on its specials AFAIK, you could give it an unique attack name, i.e. "attackprobe", and give it a non-unique description, such as "sword". That way you could still filter on the 'attackprobe' hits and apply the effect to the victim (second_unit). Of course, making this in theory is easy, the problem is to make it real. Should not be too hard, either.
EDIT: sorry, I forgot that this code is for recoloring the floating label (that one set with text=...), not the unit.
If you use the following WML code, your unit can be turned to red as if it was hurt. The effect is the same as if it was normally attacked:
Code: Select all
[store_unit]
[filter]
description=Elynia
[/filter]
variable=elynia_colorfx
[/store_unit]
[unstore_unit]
variable=elynia_colorfx
red,green,blue=255,0,0
find_vacant=no
[/unstore_unit]
The only task left would be to make it in an "name=attack_hits" event that filters on attacker's weapon name (special unit filter). Although it doesn't filter on its specials AFAIK, you could give it an unique attack name, i.e. "attackprobe", and give it a non-unique description, such as "sword". That way you could still filter on the 'attackprobe' hits and apply the effect to the victim (second_unit). Of course, making this in theory is easy, the problem is to make it real. Should not be too hard, either.
EDIT: sorry, I forgot that this code is for recoloring the floating label (that one set with text=...), not the unit.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
That doesn't actually do anything. red,green,blue= there is just for colouring the floating text you can make appear above the unit when unstoring.[/quote]Shadow Master wrote:Erm, it depends.
If you use the following WML code, your unit can be turned to red as if it was hurt. The effect is the same as if it was normally attacked:
Code: Select all
[store_unit] [filter] description=Elynia [/filter] variable=elynia_colorfx [/store_unit] [unstore_unit] variable=elynia_colorfx red,green,blue=255,0,0 find_vacant=no [/unstore_unit]
The only way I can think of to give a unit a certain kind of colouring would be to add a new standing animation (via an [object]) to the unit which would do it, and making the filtering condition for that animation such that you can "remove" it when you wish by simply making the filtering not match anymore. Of course, this is quite complex to do.
yeah, it's currently hardcoded into the C++. I wouldn't attempt to do this in WML. that's why it's in the Coder's Corner.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
It would be ideal to implement it in such way it can be done with WML, tho.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
- irrevenant
- Moderator Emeritus
- Posts: 3692
- Joined: August 15th, 2005, 7:57 am
- Location: I'm all around you.
Seconded. I just had this exact same question over in the WML forum.Shadow Master wrote:It would be ideal to implement it in such way it can be done with WML, tho.
Want to post a Wesnoth idea? Great! Read these:
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
I think that what you want is already doable, but there is indeed some hardcoded stuff to work around
First, you must know how to color-blend a frame:
Then you need to know how filter the poisoned state
Combine it in the [standing_anim] and, sadly, to work well you must also add it for all the other animations. Maybe we can add a "global to the animation or to the unit" blend_ratio, but need to think how to mix it with the frame-local one.
Anyways, now the harcoded ugly tricks:
the standard poison green blending will always be used if blend_ratio = 0, so use another blend_ratio to override it. Or a bogus 0.01 to cancel without replacing it. We also need to change this, because i don't like that the cpu uselessly real-time render this not visible blending. Or maybe i will just skip blend<0.1 at the sdl-function level.
For invisibility, use highlight_ratio, but the hardcode workaround is more imitating here, the default 0.5 highlight_ratio will be used if yours is > 0.5. Note also that a selected unit with highlight_ratio=1.0 will use highlight_ratio=1.5. We also probably need to change this and multiply by 1.5 instead of just replacing 1.0
Maybe i missed something, i just recently started to play with the anim code, but such annoying limitations make me want to try to improve it.
PS : I currently have plans for allowing to change the status icons (but i probably not enough time to do it cleanly before 1.3.11)
First, you must know how to color-blend a frame:
Code: Select all
[frame]
image="units/monsters/yeti.png"
blend_color = 0,0,200
blend_ratio = 0.8
[/frame]
Code: Select all
[unit_filter]
[wml_filter]
[status]
poisoned="yes"
[/status]
[/wml_filter]
[/unit_filter]
Anyways, now the harcoded ugly tricks:
the standard poison green blending will always be used if blend_ratio = 0, so use another blend_ratio to override it. Or a bogus 0.01 to cancel without replacing it. We also need to change this, because i don't like that the cpu uselessly real-time render this not visible blending. Or maybe i will just skip blend<0.1 at the sdl-function level.
For invisibility, use highlight_ratio, but the hardcode workaround is more imitating here, the default 0.5 highlight_ratio will be used if yours is > 0.5. Note also that a selected unit with highlight_ratio=1.0 will use highlight_ratio=1.5. We also probably need to change this and multiply by 1.5 instead of just replacing 1.0
Maybe i missed something, i just recently started to play with the anim code, but such annoying limitations make me want to try to improve it.
PS : I currently have plans for allowing to change the status icons (but i probably not enough time to do it cleanly before 1.3.11)
Moving back to WML Workshop as per... request.boucman in #wesnoth-dev (GMT-03:00) wrote: It's doable in a "reasonably correct" way via WML; but having a possibility to set unit wide animation parameters as alink suggest would be great, the thought had never occured to me...
Linking it to abilities would be even better. I'll give it some thought, but that's not top priority and won't be until some time (not 1.4 material, anyway).
I can't reply, because it wold involve logging in the forum which would mark as read all my backlog of forum posts, but feel free to repeat what I just said there...
And the corresponding code is in /src/unit.cpp, in the unit::redraw() method if he is still interested.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
How can such a kludgy and near-impossible workaround be considered a solution? This belongs in the Coder's Corner since the C++ needs to change.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
That's actually all I was really looking for here. Thnx, it's the most effective method for me thus far.Shadow Master wrote:Moving back to WML Workshop as per... request.boucman in #wesnoth-dev (GMT-03:00) wrote: And the corresponding code is in /src/unit.cpp, in the unit::redraw() method if he is still interested.
Glad that there are plans for WML implementation tho, this would be really useful for a lot of abilities.
"Don't you worry about cancer?"
"I AM cancer. I do not frighten myself."
"I AM cancer. I do not frighten myself."