UI on texture

[y0014984]

Introduction

Merging this pull request will introduce the UI on texture feature, which means that the armaOS UI is rendered also on the laptop texture and can be seen by players in a 3m circle around the laptop.

There are two triggers that force an update on the UI on texture. First, every change on the UI, for example text input/output, changing design, changing battery status etc. forces an update on this specific content. Secondly, an event handler updates all aspects of the UI on texture every 5 seconds. This should prevent the case, that someone who joins the circle later, does not get the current content of the UI, if the player that uses armaOS does not interact for a while.

A CBA settings controls wether or not a player invokes updates on his surrounding players textures. Can be forced by server.

Todos

• [x] add CBA setting to enable/disable this feature globally
• [x] add function headers
• [x] BI Bug Report for the know bug
• [ ] ~add support for snake~

Annotations

• All Updates for UI on texture are send via remoteExec to all clients in a 3m circle around the laptop. Even the update for the invoking player is done via remoteExec. If this is harmless, I wouldn't change that.
• We could modify the code, so that the updateAll function does not fire permanently but only if someone is joining the circle. For now I leave it as it is.
• The new local variable AE3_UiOnTexActive is used to determine, if a computer-display was already initialized for "UI on texture" on a specific client.

Known Bugs

• The first time a client gets an Update, produces an error. I don't know if this is an Arma 3 Bug or something that I could fix, see screenshot. The Bug is reported here: https://feedback.bistudio.com/T171035

[y0014984]

Possible Workaround to my error is to display the UI the normal way on surrounding clients first. With that the images are loaded and do not produce additional errors if shown with the UI2texture feature. Perhaps I can show and hide the UI fast enough, so the player won't see it at all. Or perhaps there is a hide feature, so the UI is technically displayed but not shown to the player. I will try to implement this workaround.

[y0014984]

@GermanHydrogen I have already done the multiplayer testing on a dedicated machine. It works.

I see your doubts about the CBA setting. From my point of view it's not that much of a problem. If the server forces the CBA setting, then it's enabled or disabled on all machines. If it's enabled, the receiver can't choose another setting. If the server does not force the setting and the sender enables the feature, then, yes, everybody in range receives the updates regardless their CBA settings. I could check the CBA settings on the receiver side, but this is quite complicated. I would need to get the remote vars from every client in an scheduled environment with your getRemoteVar mechanism on every update. This would increase the network traffic before we can reduce the network traffic. Because only a few players can be affected within the 3 meter circle, I would irgnore that theoretical problem for now. We can change that in the future if it states out as a real problem.