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.21 Beta 1 we changed the locking behavior slightly. Before 4.21 Beta 1 it was possible to set a target lock-request without having an actual target. As of 4.21 Beta 1 this will no longer work (i.e. a call to RequestSofttargetLock() without a current target will fail now -

The change was done mainly in order to realize the support for explicit target locking in gamepad mode. Other reasons behind that change were that part of the target locking design relied on target lock requests being reset/cleared, if the current target was destroyed/lost. However, the design could not rely on this behavior, since it could be circumvented by calling RequestSofttargetLock() without a target. Hence, several special/edge cases had to be covered to take this fact into account, unnecessarily overcomplicating the implementation (history lesson: this implementation originated from a quick realization to get target lock support for the mouse mode in - basically using the already realized target locking support to prevent auto-targeting overwriting the target the player clicked on / later-on this early implementation was redesigned in several following iterations, ultimately no longer requiring the lock for this case).

To simplify things (and as part of that resolve several smaller issues caused by this design flaw), we decided to restrict softtarget locking on actual targets. This also eliminates situations where mods could accidentally cause problems within the target system (resulting in cases where targeting was impossible without performing a UI-reload).

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.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

It won't matter how often you call Pause() or Unpause(). The last call dictates whether the game is paused or not. Note that the Pause()/Unpause() calls change the pause-state depending on their parameter. Hence a call to Unpause(true) will only unpause the pause state of Pause(true) (or correspondingly the case where the player hit the pause key) while Unpause(false) (or simply Unpause()) only changes the pause state of Pause(false) (or Pause()).

If you relied on the old behavior (i.e. have the corresponding number of Pause()/Unpause()-calls required), please update your script accordingly and/or let us know about your use-case so we can figure out alternative ways for you.