Controllable AutoShowMetal

[saurtron]

Work done

• Make guiHandler::autoShowMetal controllable through lua.

Related Issues

• Fixes Get rid of AutoShowMetal #1092
• Needed for Create info metal view shader and widget Beyond-All-Reason#4060

Remarks

See lua-callin-activecommand-set...rid-of-autoshowmetal for a direct comparison to parent (lua-callin-activecommand-set) branch.

• Branch on top of Add ActiveCommandChanged callin. #1848, leaving this as DRAFT until that one is merged just to avoid this one being merged before, since it includes that one.
  • Had to base on that branch since it changes very similar lines.
• Could be removed altogether but this makes it backwards compatible.

[sprunk]

Just get rid of it, the ticket contains a lua replacement. Ideally there would be a feature support tag and a bunch of forward-compatible PRs to games.

[saurtron]

Just get rid of it, the ticket contains a lua replacement. Ideally there would be a feature support tag and a bunch of forward-compatible PRs to games.

I think breaking compatibility as default policy, even if we PR to every game is not very good in general. We might not know all games (some could be private) and it puts an urgent burden on engine users (also on engine devs if we're expected to PR everyone).

Personally would rather make AutoShowMetal show a deprecated message so ppl have more time to adapt, and then in a future release (maybe even after next release), remove it.

[lhog]

I don't think we need to rid of anything. Like who is going redo 100s of maps to include #1092 (comment) widget or who is going to create configs for the same 100s of maps per each game? This is just to replicate the previous behavior.

Seems like a bunch of work (that no one is going to do) for the very little benefit.

I'd keep LuaUnsyncedCtrl::SetAutoShowMetal() but remove all deprecation warnings and keep the default coming from the map, same as now.

[saurtron]

I don't think we need to rid of anything. Like who is going redo 100s of maps to include #1092 (comment) widget or who is going to create configs for the same 100s of maps per each game? This is just to replicate the previous behavior.

Seems like a bunch of work (that no one is going to do) for the very little benefit.

I'd keep LuaUnsyncedCtrl::SetAutoShowMetal() but remove all deprecation warnings and keep the default coming from the map, same as now.

Added an example widget showing usage: gui_autoshowmetal.lua

Using that gets rid of the deprecation message, due to the call to SetAutoShowMetal(false).

It is also backwards compatible with map declaration, starting there games can implement new policies and then get rid of autoshowmetal in mapinfo if they so desire.

In a future engine release version after SetAutoShowMetal has existed for at least one cycle, we can completely remove autoshowmetal logic from GuiHandler.cpp.

[lhog]

Sounds reasonable.

[sprunk]

I dislike the existence of Spring.SetAutoShowMetal and would like future PRs to show a bit of foresight and avoid this kind of planned obsolescence, but I understand BAR is in a hurry so let's let it through.

[saurtron]

I dislike the existence of Spring.SetAutoShowMetal and would like future PRs to show a bit of foresight and avoid this kind of planned obsolescence, but I understand BAR is in a hurry so let's let it through.

Actually there is no hurry since this isn't due until a future release.

Maybe we can think of a better approach. It's important to have a deprecation mechanism, and similar situations will likely arise in the future.

I agree having a method just for that is a bit awkward. We could have a more general method, like Enable/DisableFeature maybe, or Enable/DisableComponent, but doing it without more thought could also mean we add something that has a short life because of later finding a better or more general way.

I think EnableComponent(name, enable) is probably what we will need in the future for other things too, but bit early to say right now.

[sprunk]

In this case the Lua replacement is confined to a single widget so it can be PRed to games, and then engine only touched once the gameside PRs are in.

[saurtron]

so it can be PRed to games

I don't think PRing to games is an engine developers "job" tbh. Engine developer job is improving the engine and clearly communicating changes through deprecation methods so game developers have time to adapt at their own pace.

Also that point of view assumes we know all games and are able to PR them, but that doesn't need to be the case and assuming that is going to be problematic, anyways lets better have that discussion elsewhere if it's needed. Here I'd discuss for a more generic deprecation method like I was proposing, but not about the need for deprecation itself.