Your post’s wording is somewhat confusing. I can’t really tell if you’re for or against this change.
In case you’re against it, keep in mind that FE determines whether changes made from the client will replicate to the server or not. In other words, if hackers try to change/remove objects or properties in-game, it will only show that change/affect them on their screen, while the rest of the server can play in peace.
As already stated by OP:
The option to choose whether or not it’s enabled in your game is like, as you said, flipping a light switch in a house with no power. That’s why it’s being removed…
It’s about time this happened, FilteringEnabled’ behavior has been disabled for I don’t know how long now. I don’t know why this isn’t removed all together. I get backwards-compatibility and legacy purposes, but I don’t think any game even has this anymore.
Good riddance. It’s funny the property sat there for so long.
Is there any technical reason why there needs to be a behavior change? Or is it just to be a nail in the coffin and try to coerce games that do this migrating into working?
Good riddance. I honestly thought this would come far earlier. Three years after the fact is quite a great deal of time for something being rendered obsolete vs being formally treated as such.
I’m happy to see this change, and overall it should remove a useless speedbump newer developers might run into when trying to figure out what the property does.
Will this come with an alias for SoundService.RespectFilteringEnabled? It’s not too big a deal, but its name has less meaning with the removal of the corresponding property it relies on. As far as I’m concerned, a change like this is relatively useless, so it’s more a thing of curiosity than a request.
That & completeness. We could have just hidden it from the UI, but then that feels half-baked. An immutable property also makes it more obvious that it does nothing to anyone who does discover it (e.g. by enabling a Show Deprecated APIs setting we might add in the future).
I will surface this to the Sound team, but we might not be able to offer a much more meaningful name.
I still remember checking in my games and always seeing that “This game is in experimental mode. The game may not function as intended” and being extremely confused
I think you may have misunderstood the announcement.
Roblox is not removing FilteringEnabled, quite the contrary, they’re removing the option to disable it, even though it’s been forced on for years.
Given this change, what will become of this property? It still boggles my mind that this is still a thing after experimental mode was removed in 2018.
I didn’t see the post(s) already mentioning this. In light of this new change, this property should also be locked and force-set to true as there is absolutely no reason for sounds played locally on the client to be replicated to the server otherwise. All it does is open the game up to crass exploits.
I disagree, many games rely on this being set to false and it’s not particularly dangerous for it to be true.
Worst case scenario, someone plays a sound that was already present on the server (meaning they can’t choose the id) and people get a little confused.
Of course I think all new games should have this on when possible, but no point breaking the older ones.
Absolutely nothing. In the past, the property determined whether or not “Experimental Mode” was active, but experimental mode has been removed for years leaving this property deprecated with no use. Now it’s finally being removed and attempting to check it will always return true.
I’d like to see the statistic here for the “many games” that rely on this feature.
Considering how many old features that have been thrown out which had potential for backwards compatibility, that were not particularly dangerous either, this would be a small blip rather than a game-breaking change. The worst case scenario, granted the exploiter cannot play any sounds not already created by the server, is they spam-play every sound they’re able to access until they leave the game
Admittedly I have no statistic for that, I was working off of the fact that Roblox has lots and lots of places and despite the low chance of big games using it there will still be small ones that do, but I still think it somewhat needless to remove something that causes no visible issues for the platform. If this were removed, it wouldn’t break big games as I said before, but it would still break games without reason. I still think it should remain togglable (on by default), so that individual developers can make the call for what’s right for their game and hold responsibility for the consequence.
It’d be like removing PointsService, it wouldn’t break most games but some still make calls to it, just like how some games still depend on sound playing being exempt from filtering.
(And for anyone that stumbles upon this post, I’m referring to this, not FilteringEnabled)
The only time I ever set FilteringEnabled to false is when I’m testing old Gear from the Catalog. Sometimes there’s a specific function I’m trying to salvage (i.e. those fireworks that spell out the new year in an array of fireballs.) Many tools were updated by the Admins after 2018, but not all. Experimental Mode can still occasionally come in handy, but it’s obsolete for the sake of obsolescence, if that makes sense.
