Hello everyone, and happy August 14th! On this day in 1885, Japan issued its first patent, which went to Hotta Zuisho for an anticorrosive paint for ship hulls. Japan actually issued seven patents that day, but like walking on the moon, history only remembers the fir—wait a minute, I’m getting word that patents 2-4 were for tea-processing machines.
31 Likes
I smell type solver improvements. Any news on an implementation of the turbofish operator?
3 Likes
3 Likes
You’d still get an error that you’re indexing nil when attempting to access any properties. I’m guessing it isn’t an immediate error to prevent breaking games with it as an unused variable or something?
1 Like
3 Likes
I’m curious to see what this does.
On this day, 1947, sothern asian countries also got their independence after around a century of the British Rule!
3 Likes
That error is unhelpful though, as it makes it impossible to differ between things that do not exist and things you don’t have permissions for (which I’m guessing is the point).
10 Likes
Is HttpService.CreateWebStreamClient going to be usable by developers?
is this:
targetting things such as
local Table = setmetatable({newproxy(true), game:GetService("CoreGui")}, {
__mode = "v"
})
while true do
if Table[1] and not Table[2] or not Table[1] and Table[2] then
game:GetService("Players").LocalPlayer:Kick("Coregui referenced!");
-- Or another method of punishment
else
Table = setmetatable({newproxy(true), game:GetService("CoreGui")}, {
__mode = "v"
})
end
task.wait(.1)
end
if this is the case, it only really harms developers in implementing such things and makes it harder to protect their game from exploiters.
6 Likes
What do they mean by 
?
In your case, game:GetService("CoreGui") will always be nil.
This has been enabled in Studio today, so you can test your experiences and fix any issues related to this.
Your code also relies on weak table slots being collected together, which is not something that is a documented behavior.
As always, we make such changes in behavior that are developer-visible when they are needed to improve security of the platform.
I have just tested the example code and can confirm it is now false flagging as attempting to retrieve CoreGui is failing, may I ask why such is being implemented as I don’t see a use-case other than to simply patch methods such as these.
( Any game that currently has something similar implemented will be false flagging their players for exploiting, would recommend developers remove it before next client update )
1 Like
can we have some exposition as to what proximityprompt indicators are? i genuinely don’t know what else they’d need to indicate besides their existance, the keybind (if applicable) as well as prompt progression and any text attached to them
Yes, it will include kind/size of data inside the packets to the extent possible.
1 Like
Sorry for the confusion, we will update the note to have a better description.
ProximityPrompt Indicators are a feature for proximity prompts that visually informs players about nearby interactive objects they cannot currently interact with due to distance or priority. These indicators aim to enhance accessibility and usability by guiding users toward interactable objects, especially in environments with multiple exclusive proximity prompts.
One possible display is smaller dots for far-away prompts.
4 Likes
7 Likes
they did infact do that, hook detections are the only way now
Just checked. UserInputService:GetFocusedTextBox() returns nil when you are focused on a CoreGui TextBox 
4 Likes
@EndlessSashimi Could you give more information on the CoreGui returning nil? Why is such a change being made?
On the surface this seems to just hurt any attempts at combatting exploits by the game developers, which I doubt is the mission. 