If you read one of the comments on the card, you’ll see “Need web integration for changing prices.” The card also has the “BLOCKED” tag. One of the staff members will have to clarify this, but I imagine that because it involves a web-side change, it was blocked. The board is only for gameplay/studio features right now, so once it needed web integration, it was outside the scope of the board. I don’t think that the feature is outright rejected (and hope not) – just that it’s rejected from the board since it lies outside gameplay and studio.
1 Like
A Rejected column is kind of silly, because it will only ever contain cards that shouldn’t have been created in the first place. Features should be reviewed and accepted/rejected before users get a chance to vote on them. Add an “Under Review” column that disallows voting, if necessary.
Anyway, assuming everyone wants their games to be mega awesome and better than ever before, they should vote on everything involving audio. Especially sound occlusion.
3 Likes
Yes! Audio can play such a huge part, it might even make or break a game, yet most developers almost ignore it completely…
They are – Silent137 has mentioned a couple of times that they go through an internal review process before being added to the board.
Some of the features in the rejected column like this, this, this, etc, were rejected because they were unpopular. If you’re implying those should have just been left in the unpopular list and never rejected, I concur, but otherwise, they’re not bad ideas and it would have been impossible to know whether or not they wouldn’t get many votes beforehand (hindsight is 20/20). That being said, there are some seriously dumb things in that column like block coding, so I do agree that the already-existing review process needs to be a little more strict.
I guess I misinterpreted the meaning. It makes sense if the Rejected column is for cards rejected by community vote (rather, the lack thereof). Regardless, the issue with the price-params card should have been caught in the review process, so I also agree that reviewing should be more thorough.
So before any assumptions are made, let me mention that the studio workflow hasn’t changed at all: it’s only the “gameplay” section of the board (that’s been neglected for a few months 
) that’s had significant updates.
We’ve added an “icebox” section (name may change) for accepted changes that are significantly blocked or otherwise not likely to be worked on soon. Feature requests and icebox has also been split into “normal” and “mega” (names may also change) to differentiate major estimated multi-week features from minor changes.
I can say specifically with optional price parameters that there are a whole lot of blockers from multiple teams before functionality like that would be considered, so realistically I wouldn’t expect it any time soon. You can get similar functionality through creating multiple developer products or modifying the developer product price temporarily.
Did move it back to mega icebox, it may get reconsidered in the future 
2 Likes
I’m not too familiar with roblox graphics internals, but there are a bunch of reasons in general why you don’t always want to set your near clip to 0.001f or some other small value like that.
If you’re interested in some reading, try:
https://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
It seems like this problem has been solved or at least worked around in PF and other released FPS games. Do you need to do a lot of tricks to avoid problems with the current value?
Suggestion: you may want to consider renaming the BLOCKED tag. At glance, I can easily picture someone thinking it means “We don’t like this and have blocked it from ever being reconsidered” whereas I gather it really means “There are some complications that prevent this from being implemented”. If I’m correct in understanding what it means, a better name might be COMPLICATION, OBSTRUCTED, or something similar.
It’s worked around by moving the gun further away from your camera. The downside to this is that the guns start clipping through level geometry:
If you back up against any wall in Phantom Forces and look straight down, your arms will visibly clip through the wall. You can also point your gun (long guns like snipers especially) at a wall or the ground and see it clip through. AAA FPS games solve this by using Z layering for 3D objects, but it’s specific to those games and difficult to implement in a general sense – even in those AAA FPS games the solution isn’t complete, and you can still see your guns clipping through transparent objects like windows. I posted a thread a while back where zeuxcg posted a more elaborate explanation of what I just told you. With 3D Z layering out of the question, staff members have suggested lowering the camera near clipping distance in the past. 0.001 might be out the window, but the current near clipping distance seems a lot larger than that, so there should be some wiggle room we can use to make guns clipping through the level less noticeable.
Aw collision filters in Mega Icebox and BLOCKED?? I was looking really forward to that one
6 Likes
What? Wasn’t this “In Progress”? What the heck happened, I really wanted this 
No comments on the card, but I imagine it’s the same case as the price parameter card since they both have the BLOCKED tag: the feature needed something from more than just the client/studio teams.
Awwwww, really wanted that collision filter.
The near clip plane distance is 0.5. I’m not sure about the far clip plane, but iirc it’s 4056 or something weird like that.
we might want to move to your old thread if this discussion is worth continuing.
It’s 5k.
I tested on a map in like 2012.
I just tested and it’s ~4056. 4096 would have been a much nicer number :(
> p = Instance.new("Part", workspace"); p.Size = Vector3.new(500,1,500)
> p.CFrame = workspace.Camera.CFrame * CFrame.new(0,0,-(4055 + p.Size.Z/2))
Collision filters have actually been worked on by @VolcanoINC for some time now, under review.
4 Likes
One last statement about near clip plane, changing it in our system would definitely cause z-buffer resolution problems especially across different platforms (mobile).
The @zeuxcg approved solution to the clipping problem is to stay “physically correct”, that is never have the case where you would need non-correct object layered rendering. For the gun-clipping-wall case, that would mean holstering the gun when facing the wall, or otherwise preventing rotation into that facing.
1 Like
How about when the gun is being aimed down sights? It clips through it
For now, adjust your animation and object scale such that clipping doesn’t occur.