would be great

Please!

RTTextureWidget would allow us to render UI layouts on object surfaces. 3D-interactable UI, streamlined animation, playing MP4 files on object surfaces with the VideoWidget, making textures move/shift using ImageWidgets, etc.
RenderTargetWidget would allow us to render the game camera or alternative cameras into UI. If used in a layout as a child of RTTextureWidget, the camera could then be rendered on object surfaces as well (i.e. CCTV monitors).

I had RTTextureWidget rendering in an ImageWidget preview at the start of the year, it was halfway there. All that was missing was how to apply it to the object surface so it renders in the 3D world. This appears to have stopped working altogether after a recent patch, sadly.

The only "practical" options currently available for 3D UI / animated surfaces are to:
A: Rotate/swap textures on selections directly or,
B: Render a UI window over the top of everything, so it isnt really 3D but an overlay over everything. It looks fake and doesnt fit into the environment (lighting/fog/FOV/etc).

As for RenderTargetWidget, we have no way to reference the WorldEntity. Passing another object reference to SetWidgetWorld() just makes it render black.
proto native GenericWorldEntity GetWorldEntity(); isnt usable to feed it what I presume is the expected WorldEntity.

For RenderTargetWidget to be practically usable, we would also need functions to force LOD levels and/or render resolution, along with a PiP image-quality setting that clients can configure.

Being given the ability to render UI layouts and/or additional script created cameras on object surfaces would expand the modding potential substantially.

If cheating is a concern, the cameras could be server-authoritative. Clients wouldn't be able to use arbitrary cameras as render targets; instead, the server could create/authorize them and define their permitted position, orientation and movement limits, with those restrictions enforced natively. This would allow legitimate scripted CCTV/PiP systems without exposing an unrestricted client-side cameras.

Adding my DayZ 1.29 use case and retail checks:

I need a stationary monitor in a vehicle to show live video from a separate in-world camera while retaining my normal first-person/world view. The spectator-camera workaround replaces my view with a full-screen feed, so it doesn’t put video on the physical monitor.

On DayZ 1.29.163709 (Scripts Rev. 125372), the widget declarations exist, but 2_gamelib/entities/rendertarget.c is guarded by #ifdef GAME_TEMPLATE; retail diagnostics reported GAME_TEMPLATE=0, ENF_DONE=0, and COMPONENT_SYSTEM=0. I haven’t found a supported mod-side binding that outputs camera video to a model surface; the paths we checked produced black or empty output.

Could you confirm whether a supported camera-to-surface API sequence exists for retail mods, or whether an engine-side change is required? This seems related to DZG-658. Resolution/LOD controls and a client-configurable PiP quality setting would also be useful.

Following up on my earlier post (DayZ 1.29 checks) - I have now finished a controlled test ladder on retail 1.30.164078.38.

Plain-language summary (technical detail below). I want live camera video to appear on a physical monitor inside the game world - a player standing in the world looks at the monitor and sees the live picture - not a full-screen UI overlay. On retail 1.30 I could not find a supported way to do this: the render-target texture path is rejected, and the alternative (RenderTargetWidget.SetWidgetWorld) crashes the client. My ask: either enable or document a supported way to render live video onto an in-world surface, or state plainly that it is not planned. Either answer is useful.

Setup: Windows x64 retail client, isolated local dedicated server on loopback, a purpose-built test addon, one vehicle with a monitor surface (real selection index) and one in-world camera entity, no other players. I ran seven probe revisions; two failed to compile before any probe code ran (my own bugs), one session crashed the client (details below), the rest completed cleanly. The pre-existing crash-dump set was unchanged before and after every run; the one dump this ladder produced was preserved separately.

Each configuration was tested as a single changed variable, stopping at the first anomaly. Covered across the runs:

- RTTextureWidget created programmatically and as a purpose-built layout root; default flags, RENDER_ALWAYS, and the layout "force render always" property.

- Registration via SetGUIWidget(vehicle, selIdx, rt) using the real monitor selection index; also registration implied by an RTTextureWidgetClass layout root.

- Both bind orders from public examples: (a) SetObjectMaterial -> SetObjectTexture(selIdx, "$rendertarget") -> SetGUIWidget, and (b) SetGUIWidget -> SetObjectTexture -> then material. Set-once and re-assert-every-second variants.

- An independent RT readout: ImageWidget.SetImageTexture(0, rt) as a visible consumer widget, plus GetObjectTexture(selIdx) readback on the surface.

Observations - the $rendertarget token never resolves on this build:

- Every SetObjectTexture(selIdx, "$rendertarget") call logs "Picture $rendertarget not found" (98, 136, 296, 109 and 1534 warnings across five sessions), while SetGUIWidget itself returns without error. GetObjectTexture(selIdx) reads back empty at every check.

- The ImageWidget readout renders a solid white rectangle (missing-texture fallback) and never shows the RT's children - the render target composes nothing. Screenshots 10+ seconds apart show the monitor face unchanged (the pre-existing static texture).

- A purpose-built RTTextureWidgetClass layout root does instantiate (CreateWidgets and the cast succeed), but its layout children are never created under it: FindAnyWidget finds none, GetChildren() is null, and programmatic children change nothing; the "force render always" property changes none of this.

- So the token looks rejected at call time rather than a display or material problem, and it is not order-dependent - consistent with the implementation helper (2_gamelib/entities/rendertarget.c) still being compiled out of retail (GAME_TEMPLATE=0 as measured in-game earlier).

RenderTargetWidget / SetWidgetWorld:

- SetWidgetWorld(rtWidget, entity, camIdx) accepts any IEntity, but with a non-world entity the client faults one frame later: Access violation, DayZ_x64.exe+0x3cc350 (minidump preserved; call context available on request).

- In retail scripts there is no way to get a genuine world reference: GetWorldEntity() is template-only, and the EntityEvent.FRAME "other" entity is the player object.

Cross-reference: same API family as DZG-658 (RTTextureWidget / SetImageTexture, Confirmed internally). On 1.30 our UI-only consumer bind did not crash like DZG-658 - it rendered blank - so the two may share a root cause at different stages. Either way, DZG-658 looks like a prerequisite for any of this being usable.

The ask (each point now has retail evidence behind it):

1. UI -> model: make $rendertarget resolve for a world object's texture slot once an RTTextureWidget is registered via SetGUIWidget - i.e. un-guard/reimplement the GAME_TEMPLATE render-target path for retail, or document the supported sequence if one exists.

2. Camera -> UI: provide a supported way to get the world reference for RenderTargetWidget.SetWidgetWorld, and document how numbered camera indices (the "Camera ID" property allows 0-31) are created and allocated.

3. Fold the DZG-658 crash into the same work (prerequisite for the consumer path).

4. If this is intentionally not planned for retail, please say so plainly - that answer is as useful as a fix and would stop modders from building on it.

If helpful, I can supply the minimal repro addon, RPT excerpts with the exact lines above, and minidump metadata. I will re-run the same ladder on each new build and leave a one-line "still reproduces" / "now works" update so this report stays current.

Another mod, that could benefit from RTTextureWidget rather than relying on an external web API service: https://steamcommunity.com/sharedfiles/filedetails/?id=3833411645
(I did not make this mod)

Could have been done with RTTextureWidget, ImageWidget/s for the icons, CanvasWidgets for the drawings. Then the only information handled is client -> server -> other clients that need it. It may be a few kb of position data verses needing to generate and download full images.

Theres alot of use cases for these functions that we cant even comprehend right now.