clearscope on Actor.checkSight() and Actor.isVisible()

[Gutawer]

I need to check if a monster can see the player in renderOverlay to determine whether to render some stuff, but right now, checkSight and isVisible are play-scope only so I can't do this. It doesn't seem that making these clearscope should be harmful, as they are just checking line of sight between two actors, so it'd be nice if this could be done.

[Kotti]

I don't think this is possible. P_CheckSight contains calls to a random number generator which would go out of sync when being called from the UI.

[Marisa Kirisame]

wait why the heck does checksight have rng calls?

Edit: god damn it marisa

[phantombeta]

@Marisa

Code: Select all • Expand view

   if ((flags & SF_IGNOREVISIBILITY) == 0 && ((t2->renderflags & RF_INVISIBLE) || !t2->RenderStyle.IsVisible(t2->Alpha)))
   { // small chance of an attack being made anyway
      if ((bglobal.m_Thinking ? pr_botchecksight() : pr_checksight()) > 50)
      {
         res = false;
         goto done;
      }
   }

For some reason, it does this.

[Marisa Kirisame]

This Marisa feels the urge to fix the problem another Marisa has caused.

[Graf Zahl]

Sorry, but RNG issue aside, CheckSight cannot be made clearscope before we do not have a clearer picture of how this will be represented on the client side in a C/S environment, as this runs on the full set of play data and would necessitate making a full copy of it each frame - and that's too big a can of worms in the current state.

[ZZYZX]

For client we should implement renderer-based ui-scope IsVisible. IMO
That should work both for C/S and current P2P networking.

[Rachael]

How is that going to be implemented without being too costly?

[Graf Zahl]

Not at all, that's how. I won't make any decisions here before we have at least a rough picture how C/S will have its data laid out.

[ZZYZX]

How is that going to be implemented without being too costly?

With renderer reporting what was drawn? I mean, that info is already stored (the renderer collects actors for rendering before actually doing it). And it can be a flag or something similar to what I said about checking sight for particles by marking sectors rendered in the last frame by the renderer.

Once the renderer somehow marks the actors with an unique id of the frame drawn (validcount) then there's almost no overhead and the visibility check can be done using simple int comparison (including portals, camtexs, skyboxes...)

And @Graf this approach has nothing to do with networking because I doubt that the data about rendered actors is going to be absent from the client. (or that clientside scripts are going to be absent from the client)
Both makes zero sense.

[Graf Zahl]

That doesn't work because sprites are processed by sector, i.e., only a single subsector needs to be visible for a sprite in the containing sector to be run through the renderer.
That data is totally useless for analysis. You'd get far too many false positives.