Locked properties should be queryable

Feature Requests Engine Features
#1

Take HttpService.HttpEnabled for instance. Plugins and scripts should definitely be able to query this property without being able to write to it. I am not advocating that all locked properties should be queryable, but only where it makes sense.

Right now I have to write something like this:

function isHttpServiceEnabled()
	local httpService = game:FindService("HttpService")
	if not httpService then
		return false
	end
	local success, result = pcall(httpService.GetAsync, httpService, "http://www.google.com/robots.txt")
	return success or result == "Http requests can only be executed by game server" or result == "Number of requests exceeded limit"
end
2 Likes
#2

This is necessary for life.

#3
#4

Can we also get this for everything under settings?

#5

I have a feeling something like this will happen:

#6

I have a feeling something like this will happen:

Soon: that game loses all customers.

I would use it to optimize my game’s performance and aesthetic for specific hardware. If they’re on OSX, for example, I’d use the candy-looking buttons and the black cursor OSX users love so much. If they’re running a junky integrated intel graphics card on their mom’s laptop with 5 MB vram I might want to turn down my custom particle effects. There’s so many possibilities.

#7

This is the exact reason I’ve requested the ability to read settings() ages ago.

This could also be used to catch people who are cheating with certain settings - especially prop hunt clones suffer from people using Physics.AreMechanismsShown (I know this because I’m evil and I cheat).

That setting is still really useful when debugging physics online, but in cases of these games it can be used to tell regular objects from players quite easily. If we could read their settings, they could prompt players to disable that setting and rejoin.

1 Like
#8

Here’s a list of settings uses I’m writing just reading the properties. There’s way more than this.

  • Chat guis that adhere to GameSettings.ChatHistory and .ChatScrollLength
  • Add visual cues for people who have GameSettings.SoundEnabled set to false
  • If your game asks people to record videos, don’t do that if GameSettings.VideoCaptureEnabled is false
  • Collect hardware surveys using DebugSettings
  • Throttle your game’s special effects based on RenderSettings.QualityLevel
  • Like Volcano said, kick players who are abusing their PhysicsSettings
  • Kick players who are doing stupid things with their NetworkSettings, like setting PhysicsSendRate or TouchSendRate to 0
  • React faster than the admins when a settings-based exploit is discovered
1 Like
#9

Out of this list only QualityLevel can be controlled by the user though. Eveything else is Studio-only (modulo exploits).

#10

Out of this list only QualityLevel can be controlled by the user though. Eveything else is Studio-only (modulo exploits).[/quote]

Changing these settings in Studio also changes them in-game. At least the last time I checked it did.

#11

That is no longer true since a few months ago.

1 Like
#12

Regarding the original topic - we won’t do it for all locked properties (both because it could be a security issue for some, and because our reflection framework makes exposing these kind of properties to scripts non-trivial), but we can do it for properties that are valuable.

Feel free to post requests for that, but make sure to think about the use cases (and write about them!).

1 Like
#13

Regarding the original topic - we won’t do it for all locked properties (both because it could be a security issue for some, and because our reflection framework makes exposing these kind of properties to scripts non-trivial), but we can do it for properties that are valuable.

Feel free to post requests for that, but make sure to think about the use cases (and write about them!).

1 Like