Preferred lighting technology and shadows should be left for the creator to decide if people can change these settings in a specific game or not, just like with shift lock or using R6, R15 etc.
Maybe shadows but why lighting technology specifically? I mean if you meant an option to make it user chosen by the developer or set to what the gameâs is Iâm fine with that too.
bloxstrap has an option to force set graphics quality to max, thats the only way to fix it that i know of.
1 Like
I disagree. I force future and it makes games look way better because some of them have left it set to an older technology and it doesnât look as nice
3 Likes
Some games like mine are meant to run on specific graphics settings. In my case it is the opposite of your scenerio - people would set the technology from Future to for example Voxel even though the game is specifically designed to only run on Future. I am planning to make a feature request to allow creators to read the Lighting.Technology property, as of now we are only able to detect it changing. Although due to no way to check I cannot tell if the FastFlags even manipulate it.
1 Like
I donât really play Roblox anymore but when I did and used future it would only be broken in some games (for example the flicker start screen would be pitch black or the MM2 hospital map would be just white and you couldnât see) but it was nothing so unplayable I had to stop using it. Understandable from a dev standpoint but at the end of the day I think it should be up to the player
F2 menu SHOULD show everything you need, I might regret telling you that)
But dude, why does your game need to run future, the lighting is just to enhance the visuals, if they wanna drop visuals for performance, Let them.
2 Likes
then they should set their graphics quality to 1, or use the flag to lower the texture resolution (I support the idea of adding it as an official setting, it is so annoying when the decals suddenly decide to turn very low or remain high resolution when shouldnât).
1 Like
thing is, that affects render distance, which you need in competitive games. This is why fflags- or options to utilize them built into the roblox engine (e.g fps unlocker) are so needed
1 Like
I agree there should be a small range of options to manage the render distance but not instance replication like with streaming enabled. It should also not depend on the graphics settings.
1 Like
Exactly, but roblox wonât add these settings even though they have the tools to, it makes everyoneâs life better, it lets players play over 30 fps, it prevents fflag cheaters and lets developers use certain fflags, its all around good for everyone if some of these got added as actual settings
1 Like
Counterarugment: Many developers design their games with a specific lighting technology in mind. If a user changes it, they could see the game in an unintended state, which at best just means it looks worse, but it also means they could end up cheating in a sense. Especially if you switch from something such as future to compatibility, it makes it immensely easier to see whatâs happening which could be a heavily unfair advantage.
As an example, hereâs my game as per itâs usual lighting and then with compatability:
It becomes immensely easier to see whatâs going on (which isnât what I want in this case), and the original dark mood of the scene is pretty much ruined!
Rather than advocating for flag access so that players can save performance by using a less expensive lighting technology, you should be advocating for better client settings which allow them to control things like render distance and quality separately.
I agree that having performance options is great, but youâre fighting in the wrong battle here!
6 Likes
Idrc if they keep certain flags accesible (most likely according to what doge said before) or add client settings, an idea i proposed is the ability to âlockâ the lighting engine, which would make it say set by developer, (or you can select multiple that the user can choose to in your game, especially useful since future lighting is sometimes buggy, so users would be able to choose between future and shadowmap. If only one is chosen, it will say set by developer.) similar to camera/shiftlock. But if it isnât locked, user should be able to set it to whatever they want.
This can be true for shadows too, where developers can add a minimum setting and users can only change to graphics bars above this minimum. The amount of bars that are set by developer will be in dark blue instead of light blue.
Definitely NOT rendering engine, itâs buggy and users should determine what gives the best performance on their system, and developers can already force particles to max if they really care. Pretty much nothing else developer set. There should also be 21 bar sliders by default, or atleast ab option.
If I join a game and my performance settings are capped im probably leaving though. Iâont even want this to happen, but youâd have to compromise with other developers if you really want performance settings. I just know roblox wonât make them for a loooong time so fflags are the way to go for now.
Also you should add more fog to that map lol
1 Like
Does that mean I wonât be able to enable Fast Flags on the Client anymore that donât do any harm? D:
I am mostly enabling this one all the times
"FFlagEnableInGameMenuChrome": "true",
and a few more (25 more to be exact)
Â
I do note though that some of these Fast Flags are being created from a different context. Some are being defined through the Engine itself and some are defined through Lua Contexts. It would be great if the Lua ones wouldnât get affected by this.
Â
I recently found out about FFlagCameraFarZPlane and I actually donât understand how this Flag is not removed and put as a new Property on the Camera called FarPlaneZ âŚ
It actually bothered me so much that I wanted to figure out how to make a valid bug report, to move the Fast Flag into the Camera property, because it is very useful and a way to cull things for games that are only 2D.
But 
1 Like
So the bug report has been marked as fixed, I havenât been caught up so does anyone know what happened?
1 Like
The âDFIntSolidFloorPercentForceApplicationâ fast flag needs to be removed for sure, it seems to be used by many Bloxstrap users to âStick unanchored parts the playerâ . I imagine it can be used for more malicious reasons as well.
This causes them to be flung in my game, and there doesnât seem to be a way to prevent it as it is a fast flag.
Looking forward to this fix!
Can you please confirm that the ability to choose the rendering engine will be a supported feature of the client when fast flags are removed? I use fast flags to enable the Vulkan rendering engine as it vastly improves performance on high-end desktop devices such as my own, they especially reduce the impact of poorly optimised or heavily-detailed experiences.
1 Like
Are you not able to read the value of the lighting engine using a script? Why not have an anti-cheat against it that simply destroys visibility, i.e. dense dark fog, disables lighting etc.
You canât see the technology property of lighting in a script, its protected by RobloxScriptSecurity. Also, I donât think the fflag changes the property itself but rather just forces the lighting engine to use whatever is set
1 Like