Text screens 'de-load' after a while

[Mors-Quaedam]

Players on my DarkRP server have noticed how text screens 'de-load' (for want of a better phrase) over time.

[Nebual]

I'm not positive whats causing this, but I could make E'ing screens reload them for that client.

Can you think of any information regarding reproducing it? It probably affects all GPULib based screens. Does it happen to all players, or just clients that go far away or something?
Might there be more than 32 screens at one time and its trying to reuse old ones?

[Divran]

There's a special menu for reloading most wiremod screens, called "Fix RenderTargets", found under "Wire - Display"
EDIT: or the console command "wire_rt_fix", which is the same as using the "Reload All" button found in that menu.

[AbigailBuccaneer]

Is the root cause of this a Garrybug?

[Nebual]

I would love to squash this, if anyone has more information on the circumstances of its occurrence. Its going to be something about it updating, or a bunch of entities being created, while you're not in its PVS, or not in view of it, or something.

It doesn't appear to be the same bug as that which plagued Holograms losing their scales/clips, the root cause being that sometimes the clientside source entity is deleted, and when it gets reattached to its lua part, it needs to be rescaled.

[TomyLobo]

no reply in 6 months - maybe the issue simply disappeared? I'd say do the E thing and close this until someone else reports it

[TomyLobo]

oooh better idea: set a flag on screens that were never updated with server data.
if that flag stays for more than a second or something, request data from the server

[Nebual]

Regarding your second post, the screens do get serverdata and do display properly, for awhile, but eventually the GPU part of the screen stops rendering (hence you don't even see the black background).

At least, thats what the pictures show. Its been awhile since I last experienced it myself, I didn't get to look at it closely.

[TomyLobo]

how is that even possible?
the reference to the gpulib and the reference to all the server data is kept in the same entity table, no?

[AbigailBuccaneer]

Last I recall (i.e. GMod 12 era), it was possible to somehow 'lose' a rendertarget - and this sometimes happened during a lagspike. I'm really not sure of the specifics; it was an engine bug nobody could seem to do anything about.

[Mors-Quaedam]

This still happens on my server, and yes, the entire black background
disappears still. It usually happens during a lag spike too. Wire_rt_fix
fixes it.

[Nebual]

@Mors-Quaedam: Could you try changing wire/lua/wire/gpulib.lua L195 from timer.Simple(0,function() to timer.Simple(0.2, function(), and seeing if that prevents the problem? I don't know of a reliable way to generate the bug.

My idea being that GPU:Finalize() is called by all wire screens in ENT:OnRemove (which can be called clientside during heavy lagspikes). My first guess would be that timer.Simple(0, func) is sufficient, but I suppose that might depend on where in the frame the lagspike occurs (before or after timers are checked). 0.2s should certainly guarantee it occurs in a new frame.

[TomyLobo]

code reference: https://github.com/wiremod/wire/blob/master/lua/wire/gpulib.lua#L195

[Nebual]

@Mors-Quaedam: Did that change seem to fix the glitch?

[AbigailBuccaneer]

@Nebual is it worth just committing that and hoping it fixes this?

[Nebual]

Wouldn't harm anything (since its just slightly delaying the release of an RT), and IIRC it fixed my experiences of the bug. Committing