InsideQC Forums

czg07 is the only place where this issue has been observed so far, but reQuiem isn't widely used yet. It's a fundamental enough problem that I wouldn't be surprised to see it manifest in other situations.

Here's an extremely-cut-down version of the issue comments:
=====
skychain is a linked list ...

Thanks for poking around at this some more. :)

So, looking at the patch above:

void CL_LinkEntity(entity_t *ent)
{
extern qboolean scr_drawloading; // Baker added
if (scr_drawloading) // Baker added
return; // Baker added

if (cl_numvisedicts < MAX_VISEDICTS)
{
cl_visedicts[cl_numvisedicts ...

Welp! That's confirmation, thanks.

Guess the most prudent fix for reQuiem would be to change the skychain management so that it doesn't implode when there are duplicate cl_visedicts elements.

make sure cl.worldmodel->needload isn't set, and if it is, don't draw it?


Hmm yep, that sounds like it could keep this particular case from happening, but it seems like there's a root cause that should be addressed. There are lots of spots that will call SCR_UpdateScreen, which will (down the ...

Baker wrote: Do you have a particular reason you suspect visedicts is the problem?

Details at https://github.com/SpiritQuaddicted/reQuiem/issues/9

Duplicate cl_visedicts entries can cause a loop in skychain. (This part isn't speculation, it's something I observed.)

The crashing part is the linked list (skychain), which is something new in reQuiem.

reQuiem's handling of cl_visedicts (which allows/causes duplicate entries) doesn't seem to be notably different from other NQ engines, although of course I could be missing something.

As a learning experience (and out of curiosity) I've been looking into some of the known issues of the reQuiem engine. Some I can track down just from general C debugging, but in other cases I need to pick up more understanding of the Quake data structures and how they're used.

In one case, I see a ...

I feel... different. More "active" somehow. Odd. But nice!