Ability to add parts to the popper camera blacklist

[Quenty]

As a Roblox developer, it is currently too hard to blacklist parts in the popper camera without using a hack to bind before and after the camera update. This makes it very hard to blacklist items the user is interacting with.

Right now I have a hack implemented to avoid forking the popper camera. This uses some really bad code and can be seen here:

https://gist.github.com/Quenty/75d39d43fd8b8d92eedf31954782f6d5

Fixing this would result in much more performance friendly code, or allow me to not for the camera script.

Good camera controls are critical to good gamplay on Roblox. Having a solution to this would be really good.

[Reditect]

This is 6 years old, but I’m sure someone else will run into this issue. I spent many hours trying to figure out all of this. This is what worked for me: Roblox Poppercam Ignorelist

---

Note on Parts vs Model

We can simply put the Model, not each part or children/descendants. It’s better, or easier at the least, than parts:

Scripting Tip: PopperCam Manipulation / How to have specific objects collide with the camera

In your model example, just insert the model itself into the ignore list instead of inserting its children one by one. GetLargestCutoffDistance (the method used by PopperCam to determine how far to push the camera forward) ignores the descendants of instances in its ignore list, too. [image] table.insert() automatically inserts elements at the last index of the array when the position isn’t specified. Just table.insert(ignoreList, v) is fine.

---

The Path for the Popper

The crux of the issue, though, is needing to fork Roblox’s PlayerModule, instead of having an accessible point to add to via require(path_to_popper_module). Actual path is:

local PlayerModule_Popper = require(game.Players.LocalPlayer.PlayerScripts:WaitForChild("PlayerModule").CameraModule.ZoomController.Popper)

Note:

New Player Scripts are coming (10.11.18), and how you can prepare

Just a heads up, since it seems to be a fairly common mistake to make–requiring modules from StarterPlayerScripts–and the resulting bugs are difficult to diagnose if you don’t know what you’ve done wrong, I’m probably going to add a safeguard against this to the top of each of the player scripts ModuleScripts, something like this: if script:FindFirstAncestorOfClass("StarterPlayerScripts") ~= nil then error("Do not require modules directly from StarterPlayerScripts, require the copies cloned…

---

PopperCam & Popper?

What’s made things a little confusing as well is that there’s the PopperCam and a Popper Module, two different things. They likely interact at some point, but the whole “Exclusing” Models/Parts seems to have been moved from PopperCam to Popper at some point. That made following older links on this confusing.

---

CameraAPI?, Removal?, and Forking Issue

Along this journey, I found this Do *NOT* remove the CameraModule API?, which I didn’t even really know there was a CameraModule API, and there was the CameraModule API Public Override. I’m not sure what the state of that API is at the moment, but the feature request (first link) by Max had this:

@Maximum_ADHD

To my understanding, the whole point of this system refactor was to avoid having to fork Roblox’s CameraScript to make changes to it, so this change is very unusual.

And, that’s where I’m at now with THIS thread/feature request…

---

My Ask for @AllYourBlox

My understanding of modules isn’t amazing, but wouldn’t something like this solve the issue?

local Popper = {}

Popper.excludeList = {}

return Popper

This way, we don’t need to fork the Popper Module, and by extension, the entire PlayerModule script. We could instead use require with the path, and simply do

local PlayerModule_Popper = require(game.Players.LocalPlayer.PlayerScripts:WaitForChild("PlayerModule").CameraModule.ZoomController.Popper)
table.insert(PlayerModule_Popper.excludeList, ModelHere)