New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.17 terrain-graphics macros clean-up #6606
1.17 terrain-graphics macros clean-up #6606
Conversation
please add |
There's a whole deprecation headache to deal with at the end. Don't worry, I'm not trying to break UMC. |
Thanks a bunch for working on this. |
I can't do much to help with moving to a new engine, but this is the one thing I can do to at least make it more manageable. I think most of the old macros are unused now, the last thing to deal with is WALL_TRANSITION*. Do the terrain macros need to have some formal deprecation process with logged warnings? Or is it enough to move them to a "deprecated" directory? Getting wmllint to automatically change things seems unrealistic. If the old macros still work, but are clearly marked as not relevant for mainline or future content, that should still achieve the goal of getting them out of the way of future development. |
The process would just be adding |
Well, that doesn't sound so bad. Something to look into next week. |
What is the right deprecation level for the old macros, can it be level 3 or even 4? |
I think that was a Travis thing that GitHub Actions doesn't actually support.
It depends on the intention.
You shouldn't use 4 unless you absolutely have to. If you do use 4, the macro itself would probably either do nothing but contain the deprecation message, or it would do something that only vaguely approximates what it used to do. If the intention is to get rid of these macros as soon as possible, the correct deprecation level is 3. That said, you should probably check with @Pentarctagon for approval before using level 3. |
{OVERLAY_COMPLETE_LF Ss (!,Xv,Chs,!,C*,H*,M*,X*,Q*,A*,Ke,Kea,Kud*,I*) -85 base2 swamp/reed} | ||
{OVERLAY_COMPLETE_LF Chs (!,C*,K*,Ss) -85 base2 swamp/reed} | ||
{NEW:OVERLAY Ss swamp/reed LAYER=-85 FLAG=base2 ADJACENT="!,Xv,Chs,!,C*,H*,M*,X*,Q*,A*,Ke,Kea,Kud*,I*" } | ||
# {OVERLAY_COMPLETE_LF Ss (!,Xv,Chs,!,C*,H*,M*,X*,Q*,A*,Ke,Kea,Kud*,I*) -85 base2 swamp/reed} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old versions commented out should be removed entirely before this is merged. I realize this is still in draft though, so probably not a priority right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm leaving a lot of that stuff in for now until deprecation is worked out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine. As long as it's gone before it's merged.
data/core/terrain-graphics.cfg
Outdated
@@ -657,12 +677,17 @@ C*,K*,X*,Q*,W*,Ai,M*,*^V*,*^B*,_off^_usr#enddef | |||
{NEW:CASTLEWALL Km (!,Km,Xu*,Xo*) K* castle/aquatic-castle/keep} | |||
|
|||
# disable the next line to get the brown bank transition. It adds more images to the hex though. | |||
{DISABLE_BASE_TRANSITIONS_F (Km,Cm) non_submerged} | |||
{DISABLE_BASE_TRANSITIONS (Km,Cm)} | |||
# I don't remember what these were for, and can't see that they make a difference |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does anyone else know the purpose of these?
It's probably unlikely for a GUI toolkit replacement to make it into 1.18 (unless maybe if we go with TGUI and it's exceptionally simple to swap in), so I'd say deprecation 2 for now, and then hopefully deprecation 3 or 4 in 1.19. |
I don't quite understand what that has to do with this, but okay, sure. |
Thanks. 2 it is. |
From the PR description, one of the motivations of this is to simplify what we'd need to potentially re-implement if we were to end up switching to a different GUI toolkit. At which point any functionality specific to these macros wouldn't need to be redone, and they could just be removed instead. |
Okay… well, if I recall correctly, anything deprecated at level 2 or above can be removed whenever we feel the need to, provided there has been at least one stable series in which it was deprecated. (If it was deprecated at level 1 I believe it would need to be promoted a level for one series before removing it.) So, it sounds like the correct answer is indeed:
|
@@ -1,6 +1,9 @@ | |||
#textdomain wesnoth | |||
|
|||
#toplevel macros to handle base tiles | |||
# These macros are legacy code, the entire file can be retired | |||
|
|||
#deprecated 2 1.19.0 Any terrain macro with a TERRAIN_BASE_* name pattern is being retired and uses deprecated internal macros |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not the correct way to deprecate these. It will result in the deprecation message being shown always. You'll need to copy-paste this line into each macro individually.
Basically, this deprecation message is shown when someone includes this file as {core/terrain-graphics/deprecated-base.cfg}
, but the core _main.cfg does this, so it will always show.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, thanks.
I've tested this in the editor, the test scenario, and a few MP scenarios in case there was anything surprising there, and it seems to work. I plan to merge this if it passes CI and no one has objections over the upcoming week. This isn't completely optimized, but I think the bulk of the legacy code is contained. New/updated macros start with
Overlapping (out of hex) images, animation timing, and optional arguments weren't always available, a lot of the old macros were a method of working without those features. |
@Pentarctagon - According to the roadmap, 1.17.3 is due tomorrow, is it better to merge this before or after? I don't think it will change anything it wasn't supposed to, but I could have missed something, so I'm not sure if it needs to stew in a "1.17.x+dev" version first. |
I'd say go ahead and merge it. |
* updates to desert terrain * ^Bsa snowy stone bridges * fix wooden bridge bug introduced by #6606
I'll try to clear out the unused and used, but not really needed, terrain-graphics macros, so that migrating to a different graphics engine is less daunting. This will take a while to reach merge state.
In general, I believe many (most?) of the terrain macros are legacy, and no longer really needed. Most terrains can use one of the NEW:* macros, those are the ones to keep and update. The *_PLFB-style and "meta-macro" + auto-generated rules are prime targets for removal, but the NEW macros aren't quite ready to take over as-is.
First thing to tackle is to replace the OVERLAY_* macros
EDIT: and I tried to skip CI from memory, but didn't get it right, apparently.