We’ve updated the public Trello with a couple of potential long term high-impact projects. Please vote for the ones you most want to see happen!
(See column Vote For Feature Requests - Mega and filter for label Gameplay).
We’ve updated the public Trello with a couple of potential long term high-impact projects. Please vote for the ones you most want to see happen!
(See column Vote For Feature Requests - Mega and filter for label Gameplay).
Can this be moved? It allows objects to be closer to the camera before they’re clipped. It has 29 votes but is in the ‘unpopular’ section.
30 votes over the course of a couple months isn’t “terribly” popular.
I also don’t really see the need for a change like that (wasn’t any post linked).
Is there any specific use case you’re pushing for here?
I’ve seen threads about it before. I think @Litozinnamon can attest to it.
Its mostly about things like aim down sights. Allowing guns to be closer to the camera to see through the sights.
Yes!
In my FPS game it’s difficult to aim down sights without clipping. I’m sure the PF devs would appreciate it as well.
I’m going to be the one that says it but I am not particularly happy with how the Trello board is being altered.
The idea of the board was so developers could help ROBLOX as a company push new features that they really wanted, however half of the features are being blocked or marked as unpopular by staff members who should remain impartial to this. If we don’t want something it is not going to get the votes, and if we do then it will.
In reality we totally understand that it is ROBLOX that will have the final call, but the idea of the board is to tell you what we want, so it should reflect what we want. The most popular feature request was moved into rejected yesterday for example, but in my opinion as the most popular it should remain in the original column so that if it remains the most popular it can be reevaluated at a later date.
Apologies for the rant and if I have misunderstood something but I really feel like the new structure of the board is not suitable for it’s original purpose and seeing that the most popular feature request was moved to rejected makes me question if the board is worth having at all anymore.
Noice.
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.
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.
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
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
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.