HUD: support float values for text size property

[Zughy]

Fixes #16603

size.mp4

⬅️ master
➡️ PR

(code below)

It's my first time really messing with the networking part, as I wanted to learn a bit how the engine works. So... heh.

I didn't want to add another property (e.g. font_size), as I'd like to avoid any additional work to game devs. So I've converted size into a v2f. I've tested both with new server - old client (as in video) and vice versa.

To do

This PR is Ready for Review.

How to test

function animate(player, HUD_ID, old_val, decrement)
	local val = old_val + (decrement and -0.2 or 0.2)
	player:hud_change(HUD_ID, "size", {x=val})
	
	core.after(0.1, function()
		if not core.get_player_by_name(player:get_player_name()) then return end
		
		if val > 5 then
			decrement = true
		elseif val < 2 then
			decrement = false
		end
		animate(player, HUD_ID, val, decrement)
	end)
end

core.register_on_joinplayer(function(player)
	local HUD = {
	    type      = "text",
	    position  = { x = 1, y = 0.5 },
	    offset    = { x = -25 },
	    alignment = { x = -1 },
	    text      = "AAAAA",
	    size      = { x = 1.8 },
	    number    = "0xff0000",
	}
	local HUD_ID = player:hud_add(HUD)
	
	animate(player, HUD_ID, 1.8)
end)

[Wuzzy2]

Works for me. I also tested minimap. 👍

Please note the size attribute is used for a few other HUD types, like minimap, compass and statbar, where the values are used for pixel sizes or percentages. Pixel sizes are best stored as integers, so switching to float feels somewhat dirty. On the other hand, the float imprecision problems won't kick in until very large numbers.

So I can can get behind the case for adding a font_size instead, and reading from size for the text size only as a fallback (if font_size is undefined), so that existing mods still work. This solution might be the "cleanest".

But either way, I don't care that much as long it works; the problems with a float size are mostly of theoretical nature.

Also, I noticed this: if I use size={x=320.999, y=320.999} for minimap, this now looks different than size={x=320, y=320}. Not sure if this is intended or not.

Finally, should the documentation mention that floats are accepted now? (In general, I think the documentation would improve if data types (esp. float vs int) and size bounds (min/max value) are mentioned everywhere, but this is off-topic …)

[Zughy]

if I use size={x=320.999, y=320.999} for minimap, this now looks different than size={x=320, y=320}

I wanted size (as a float) to be used only for text. And since no field type is specified..

I can can get behind the case for adding a font_size instead, and reading from size for the text size only as a fallback

I didn't want to add a new field. However, if core devs think this is the way to go, just tell me and I'll go with this approach instead

[Zughy]

Actually, this can be considered "UI improvements". Relabelled, if core devs don't agree, feel free to close it as not adhering to the roadmap.