Target element handling (default UI connections)

In 4.20 21 Beta 1 the way the UI system treats connections with the UIui-tag was changed in such a way that as of per 4.20 21 Beta 1 default UI - connections are required to only have a single tag (the ui-tag). Before that change, default UI - connections could have other tags in addition to the ui-tag.

The problem with the old behavior was that in certain asset set ups, the UI would select the wrong UI- connection onnection (mistakenly taking a non-default ui-tag for a default one). While the assets in a vanilla game are supposed to not suffer these problems (aka: where the game used a default - ui - connection, the chosen ui- connection in the end practice always was always the default one), it's possible for mods to have created/changed assets resulting in the wrong connection being used.

The actual player visible/notable effects are quite difficult to describe in detail, because they depend on several game states which are not linear to reproduce. Notable problems ranged from wrong or duplicated target elements having been displayed, cases where the wrong target was selected or others were not selectable , other targets not being selected at all, or up to less perceptible issues like timings where a target element changed were slightly to change the current target being off.

We don't expect that any mod out there actually ran into this problem though, but if you did and you expected the previous old behavior, feel free to leave a comment here.

Note: This change is not documented in the UI-modding notes, since it's related to an asset definition change and not exactly a change on the UI-system.

Removed

...

"no

...

target" locking

In 4.20 21 Beta 1 we changed the locking behavior slightly. Before 4.20 21 Beta 1 it was possible to set a target lock-request without having an actual target. As of 4.20 21 Beta 1 , this will no longer work (i.e. a call to RequestSofttargetLock() without a current target will fail now -

...

If your mod relied on the old behavior (i.e. being able to prevent targets being selected), please leave us a comment and we'll try to find a suitable solution for you. We however don't know of any mod out there which relied on this (undocumented and not really obvious) behavior. That said, we don't expect this behavior change actually breaking any mods out there.

Changes to handling absent color values

The two Lua functions CreateIcon() and SetIcon() accept optional color values. If the color values are omitted, the icon color should be unchanged (to whatever it was set before). Due to a bug (see

If you relied on this behavior, please correct your calls of the function and explicitly specify the white color value. If in doubt or if you run into issues, leave us a comment and we'll look into it.

Changes to Lua Pause()/Unpause() functions

Prior to XR 4.20 21 Beta 1 it was required that each call to the Pause() function in Lua has a corresponding Unpause() call to actually unpause the game. Since this is error prone (i.e. if you miss a single Unpause() call, the game would still be paused and you'd have to restart the game since there's no way to recover from that state), we decided to change the design (see

...