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

• add CBA setting to enable/disable this feature globally
• add function headers
• 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.

[GermanHydrogen]

First of all: Nice work, awesome feature.

I think the way in which you are using the cba setting variable AE3_UiOnTexture,
does only mean, that a client with uiOnTexture turned off does not broadcast the updates to other players. In case of updateOutput the update push depends on the server setting.
A way to solve this, would be to include a filter to getPlayersInRange instead, to only get players which have the feature enabled. This would also reduce traffic.
The other possibility, would be to check directly in the uiOnTex update functions.

I did not test the feature in dedicated multiplayer.

[GermanHydrogen]

Why do we need to update regularly? Isn't everything pushed when it changes?

[y0014984]

Yes, everything is pushed, but if player A uses the Terminal and only reads it without any interaction, there is nothing to push. If player B enters the circle, he won't see the actual content/interface. Imagine a player is not sitting in front of his real life computer and blocking the laptop, or thinking very long about the next command or perhaps unconciousness. That's why there will be an auto-push-interval.

[GermanHydrogen]

Why apply the per frame handler, if the feature is disabled?

[y0014984]

This function is only called once. Otherwise I would need another place to check regularly, if the feature is enabled or not. For me this is the easiest way of implementation to add the check directly to the event handler. But if you have any suggestion to do it better, I would be happy if you tell me.

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

[GermanHydrogen]

LGTM