Monitor target handle rewrite

[GliitchedEntity]

Added RadarTargetExtender class, which (Hopefully efficiently) handles if current monitor target needs culling for both Players and Radar boosters.

[GliitchedEntity]

Good points. Didn't think that there could be multiple monitors I guess it can be fixed by caching targets for each monitor… About GetComponentInChildren, it is expensive, but it's only used once camera target gets switched or player enters/exists the building. Still worth looking into other ways of doing things. You think it's worth improving or currently used method should do the job?

[2394425147]

A downside to this approach is that we only assume one singular monitor and that the radar target doesn't change often When the target player changes, you need to get its PlayerControllerB(or RadarBooster) component, which is a bit expensive, so if you have more than one monitor, you'd be performing a GetComponent for every monitor every frame since only one result is cached

Let's imagine 2 players outside the building walking in, player A walks in first, and both players have handheld monitors targeted at each other

Using the current solution in CullFactory, we simply get player A's cached component from StartOfRound, skipping GetComponent, and do a type check on A's items to see if it's a RadarBooster Then, we store the player and the radar booster's transform inside a list B sees A walking inside just fine, since a List.Contains lookup isn't too expensive there's no hiccups either, and A sees B just fine too

In this proposed solution, although we do cache player A when he walks inside, that information is immediately discarded because both monitors are pointing to different results: Since playerB != cachedTarget, the if (TargetIndex == cachedradartarget && !force) check fails, so it caches playerB And in the same frame, playerA != cachedTarget, the if (TargetIndex == cachedradartarget && !force) check fails again, so it caches playerA This procedure is repeated every frame

[2394425147]

About GetComponentInChildren, it is expensive, but it's only used once camera target gets switched or player enters/exists the building. Still worth looking into other ways of doing things.

If multiple monitors are present, the GetComponentInChildren branch gets executed for every monitor on every frame so it's generally not advised

[GliitchedEntity]

If multiple monitors are present, the GetComponentInChildren branch gets executed for every monitor on every frame so it's generally not advised

I understand 👍 Cache misses every time if two monitors with different targets are present Which causes GetComponent call every update tick The solution to this would probably be to have cache for each monitor. But then it wouldn't be better than what's in the master branch