Support question

Does the current retail DayZ Windows client support rendering child UI widgets into RTTextureWidget and consuming it with ImageWidget.SetImageTexture? If supported, is there a minimal DayZ-specific example demonstrating allocation, first-render readiness, updating, consumption and disposal?

The eventual goal is UI on a handheld model, but the latest failure occurred BEFORE SetGUIWidget/model binding. We need to establish the UI-only producer/consumer contract first.

Observed environment and failure

DayZ 1.29.163709, Windows x64, windowed 1020x768. The original test environment included CF, VPPAdminTools and a combined mod pack. This has NOT yet been reproduced in an otherwise vanilla isolated test addon. Please do not treat this as proven engine-only causation.

An ordinary phone menu remained outside the RTT. A separate diagnostic panel displayed an ordinary reference and an ImageWidget consumer. The RTT contained only seven simple widgets (root, coloured panels and text), no ItemPreview, no captured phone layout and no diagnostic-created entities/RPCs.

RTT and its child rectangles were explicitly configured before attaching the consumer. Both target and pattern reported 0,0 256x512. The consumer was not a descendant of the RTT. Source updates were scheduled 80 ms apart. This was only a script update interval, not a native GPU cap or readiness guarantee.

At the third update, the diagnostic called ImageWidget.SetImageTexture(0, target), then SetImage(0). The following log record completed. SetImage's Boolean return value was not recorded. The next RPT crash record was about 11 ms later.

The user reported a white right-hand field before the crash; its exact timing relative to the bind is not established. There was no stage-2 request and no diagnostic SetGUIWidget/model binding in this run.

Condensed timeline from RPT and minidump (log messages paraphrased)

18:13:11.298 bounds: target=0,0 256x512; pattern=0,0 256x512

18:13:11.299 external ImageWidget consumer attached; no diagnostic model binding

18:13:11.310 engine crash record

Exception code: C0000005 ACCESS_VIOLATION at 00000000

Minidump exception parameters: [8, 0]; exception address: 0

The text crash report described a write, but the actual minidump exception record indicates execute/DEP at address zero. No symbolized stack analysis or driver attribution has been performed. The diagnostic is now removed from execution; ordinary phone use works in the recovery build.

API questions before another experiment

1. Are RTTextureWidget and ImageWidget.SetImageTexture implemented for this retail renderer, or are these declarations only usable in a different engine/template configuration?

2. Does an RTT require a specific layout property, root hierarchy, resource format or initialization phase beyond Workspace.CreateWidget and generic Widget sizing?

3. Is there a supported way to know that the native texture is allocated and its first render completed? Widget.GetScreenSize and returning from Widget.Update alone do not establish that.

4. What is the supported lifetime/disposal sequence for an ImageWidget consumer and its RTT? Are any scheduling restrictions documented?

5. Separately, is global SetGUIWidget(entity,index,RTTextureWidget) supported on DayZ RV materials? If yes, what does index select, and what material/shader setup is required? An earlier Stage0 $rendertarget attempt produced an unrecognized-texture warning; this was a DIFFERENT run from the UI-only crash.

References

https://github.com/BohemiaInteractive/DayZ-Script-Diff/blob/86974a0f5bd16b1ee3e334ad828133c93dca80a1/scripts/1_core/proto/enwidgets.c

https://github.com/BohemiaInteractive/DayZ-Script-Diff/blob/main/scripts/2_gamelib/entities/rendertarget.c (conditional GAME_TEMPLATE implementation)

https://github.com/BohemiaInteractive/DayZ-Script-Diff/blob/main/scripts/1_core/proto/enentity.c (conditional ENF_DONE SetRenderView)

https://github.com/BohemiaInteractive/DayZ-Samples

https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-exception_record

Reforger's member SetRenderTarget/RemoveRenderTarget/SetMaxFPS are not assumed to exist in DayZ. No working DayZ-specific example was found in the sources searched.

Original diagnostic source and dump are retained locally. Full logs and the dump are not attached because they require privacy review. This is a support question and record of an earlier failure; the crashing diagnostic has not been re-enabled.

Sequence of the earlier failure (not an independently reproducible vanilla test case):

1. In the modded test environment described above, open the phone UI and enable its stage-1 RTT diagnostic.

2. Keep the ordinary phone menu and the ImageWidget consumer outside the RTTextureWidget hierarchy. Use only simple panels/text in the RTT.

3. Configure the target and pattern to 256x512 pixels before attaching the consumer; inspect the reported bounds.

4. Advance the diagnostic's script updates at an 80 ms interval. At the third update, call consumer.SetImageTexture(0, target), then consumer.SetImage(0). SetImage's Boolean result was not logged.

5. The post-bind log entry completed, followed approximately 11 ms later by the native crash entry. No stage-2 model binding was requested.

This is not a claim that these steps reproduce on every installation, nor that delay/Widget.Update proves GPU readiness. The test has been disabled after the crash. We are requesting the supported DayZ-specific initialization/lifetime contract before preparing another isolated test.

If this pipeline is supported: the external ImageWidget should show the child UI rendered by RTTextureWidget, with a documented safe initialization and disposal sequence. If unsupported in retail DayZ, please clarify that limitation and any supported alternative for live UI on a handheld model.