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]

Should include forward-compat as well. This is so that games can add the widget before migrating in a fire-and-forget way, and it won't be applying conflicting changes in parallel with the native engine autometal behaviour.

Suggested change

	function widget:Initialize()
	if Spring.SetAutoShowMetal then
	function widget:Initialize()
	if not Engine.FeatureSupport.noAutoShowMetal then
	-- engine hasn't yet removed autometal and handles everything for us! arigato mr. Recoil 🙏
	widgetHandler:RemoveWidget()
	return
	end
	if Spring.SetAutoShowMetal then

[saurtron]

need to check for nil since it's now a bool and want it to not trigger the deprecation warning once this is in, so SetAutoShowMetal needs to be called when it's defined in general.

[saurtron]

...so added a variant of your suggestion.