Info |
---|
Note that in contrast to previous versions there was no 4.20 4.20 was a VR only release (without a beta phase). The XR version following 4.10 was 4.21 Beta 1. |
Target element handling (default UI connections)
In 4.20 the 21 Beta 1 the way the UI system treats connections with the ui-tag was changed in such a way that as of 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.
...
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 -
Jira | ||||||
---|---|---|---|---|---|---|
|
...
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
Jira | ||||||
---|---|---|---|---|---|---|
|
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
Jira | ||||||
---|---|---|---|---|---|---|
|
...