Suggestion for {HIGHLIGHT_IMAGE} macro
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
Suggestion for {HIGHLIGHT_IMAGE} macro
Hello,
I have a small suggestion for the above mentioned macro. Currently, only background images can be protected with the BACKGROUND parameter, but background halos are lost no matter what.
I'd suggest to change the BACKGROUND paramater to a yes/no boolean that would set if the background items (both images and halos, any number) would be protected, or erased during the blinking. This is possible by giving a name to the item being blinked. Here is an example of a possible new macro definition, highlighted where something is changed:
Great advantage is that it's backwards compatible with all
If it's worth the effort to extend backwards compatibility, then the definition
could be used, where the new argument is optional for future use, and old code will still work. It has the advantage that if you want to protect all items on the location, you can use PROTECT=yes, and if you want to protect only one specific item, and erase all others, then you can specify that as BACKGROUND_IMAGE.
I have a small suggestion for the above mentioned macro. Currently, only background images can be protected with the BACKGROUND parameter, but background halos are lost no matter what.
I'd suggest to change the BACKGROUND paramater to a yes/no boolean that would set if the background items (both images and halos, any number) would be protected, or erased during the blinking. This is possible by giving a name to the item being blinked. Here is an example of a possible new macro definition, highlighted where something is changed:
Proposed new macro def:
{HIGHLIGHT_IMAGE x y image ()}
calls, and behaves as it used to. Of course, if someone has {HIGHLIGHT_IMAGE x y image (specified_background)}
, that has to be changed to {HIGHLIGHT_IMAGE x y image yes}
If it's worth the effort to extend backwards compatibility, then the definition
Code: Select all
#define HIGHLIGHT_IMAGE X Y IMAGE BACKGROUND_IMAGE
#arg PROTECT
no
#endarg
....
#enddef
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Re: Suggestion for {HIGHLIGHT_IMAGE} macro
This is a bit hard to follow. If I understand correctly, your suggestion is to add a new version of {HIGHLIGHT_IMAGE} that, instead of taking {BACKGROUND_VALUE} that specifies a particular image to preserve, takes a yes/no parameter that means "preserve all images on that hex"? That sounds like a reasonable addition. I'm not sure if it's practical to make {HIGHLIGHT_IMAGE} support all of yes/no/()/filename for the fourth argument, though. If it is, great. If not, we can always add a new macro for the new functionality.
Re: Suggestion for {HIGHLIGHT_IMAGE} macro
Yes, that's exactly the proposition. Let's suppose you have an item with a halo animation, or multiple items on that same hex, and you want to highlight the gohere.png for the player there. The current macro will erase your background no matter what (because the current implementation can only protect items with "image", and only one item at that).josteph wrote: ↑October 18th, 2019, 1:27 am If I understand correctly, your suggestion is to add a new version of {HIGHLIGHT_IMAGE} that, instead of taking {BACKGROUND_VALUE} that specifies a particular image to preserve, takes a yes/no parameter that means "preserve all images on that hex"? That sounds like a reasonable addition.
In the meantime I defined the suggested macro for my add-on, and what's in the original post doesn't work, I had to do it a bit differently:
New macro that works and does what was suggested:
I think it could be merged with the existing macro, so that the last argument can take any of yes/no/()/filename. You could do:
Code: Select all
{VARIABLE check_on_this {LAST_ARGUMENT}}
Code: Select all
[variable]
name=check_on_this
contains="png"
[/variable]
Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Re: Suggestion for {HIGHLIGHT_IMAGE} macro
I'm leaning toward having two separate macros. With one macro it'll be two easy to forget to handle all case when we change the macro. Could you please (fix the indentation and) open a pull request for discussing this further?
Re: Suggestion for {HIGHLIGHT_IMAGE} macro
So sorry for the very late answer I was completely absent for the past week.
Sorry for the indentation, I usually use tab(4), and when I copy mainline code and insert my stuff in it, usually this happens with the
[code]
on the forums. I'll fix that and open an issue Main UMC campaigns: The Ravagers - now for 1.16, with new bugs!
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
Old UMC works: The Underness Series, consisting of 5 parts: The Desolation of Karlag, The Blind Sentinel, The Stone of the North, The Invasion Of The Western Cavalry, Fingerbone of Destiny
- Celtic_Minstrel
- Developer
- Posts: 2290
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: Suggestion for {HIGHLIGHT_IMAGE} macro
I'd rather see the functionality added as a new WML tag rather than extending the macro. I've even implemented it already, so if someone wanted to copy that to mainline, I wouldn't mind.