GetTextNumLines() returns nil when called with unavailable font/fontsize

Before 4.10 Beta 1 calling GetTextNumLines() with an unavailable combination of a font and a fontsize would return some values regardless (if the fontname was correct).

However, it then calculated the returned number of lines based on a different font size (which the caller couldn't determine directly). Hence, the output for this incorrect call was kind of meaningless to the caller.

This issue was fixed, by issuing an error in this case now and returning nil. Since calling the function with an unsupported font/fontsize is quite meaningless and it's almost impossible for mods to display any text with that invalid combination, we expect that there's no real world example out there which runs into the error case.

If however you spot a problem because of this change, please let us know.

See: 

Reduced number of visible table rows

In order to improve the performance of the engine, we introduced a feature for the UI to share the visual table rows. While this is fully transparent to modders/scripts, it impacts how many table rows can be displayed at the same time on screen.

Before 4.10 Beta 1 the limit was 50 visible table rows for each table inside a view for each of the three addon environments. Hence, in a three-table-view each of the tables had a limit of maximum 50 table rows (ultimately that's max: 3 x 50 x 3 visual table rows = 450 rows).

In 4.10 Beta 1 we share the rows within an addon environment alongside the tables now. So the new limit is to have a max of 50 rows for all used tables inside a view. In other words: If you take a three-table view, you could create an upper table with 10 visible table rows, a middle table with 30 table rows and a lower table with 10 table rows). Note that this is only a limit for the actually visible table rows. There is no hard limit for the number of table rows which are currently not displayed (hence all tables can still have more or less an endless amount of rows).

In practice we believe that even the reduced limit is impossible to reach in real world examples. Please let us know if you run into the limit here, though.

Slider widget element changes

In 4.10 Beta 1 several bugs related to sliders were resolved. Two of these fixes can however result in behavior changes of sliders used in mods, if the mods relied on the buggy behavior.

The first issue is a change in how sliders are visualized, if the min value was != 0. In this case the slider's left position was incorrectly calculated and it looked like the player couldn't select the lowest possible value. With the fix the slider now correctly starts at the intended min selectable value. If you relied on the buggy behavior, please update your script and set the minSelectable value accordingly to achieve the previous behavior, if that was the intended one.

The second issue is related to which values the slider could be set to. If the slider granularity was != 1 and the start position for the slider was set to a value so that the min or max selectable values would not ensure the set granularity, the player could first move the slider to the min/max selectable position and from there move the slider based on the granularity to the other side.

This had the result that:
a) the player could set the slider to invalid values which do not ensure the given granularity
b) end up in not being able to reset the slider to the initial value, once moved fully to the left/right

An example to demonstrate the issue would be to create a slider with a min selectable value of 0 and a max selectable value of 2, set the granularity to 2 and the startvalue to 1.

In this case the player could move the slider to either 0 or 2 and after the slider was moved it's impossible to reach the start value again.

In 4.10 Beta 1 the slider ensures that the set granularity correctly restricts the movement of the slider. In the example specified above it would mean that the player could (correctly) not move the slider at all, since neither the max (2) nor the min selectable value (0) could be reached based on the startvalue (1) and a granularity of 2 (i.e. the next valid values for the granularity would be -1 or 3 which both are outside the selectable range). If you relied on the old behavior, please let us know so we can consider adding the proper support for your use-case.

See:

Icon widget element nil-color behavior change

Before 4.10 Beta 1 the behavior of an icon which didn't specify its own color (aka: passing nil for its color values) was for it to be colored according to the background color of the table it's used in. This led to the fact that it was not possible to use non-gray-scale icons/textures in tables directly.

A workaround for this was to specify a gray color value for these icons/textures. This however was quite unintuitive to use. Therefore in 4.10 Beta 1 we changed the behavior of icons in the widget system so to no longer alter the color value of icons which don't specify a color in the CreateIcon() call.

We doubt that anybody relied on the previous behavior (which resulted in the icon being colored based on the background or highlight color of the table row). If you relied on this behavior, feel free to drop us a note.

See: