You can still set it through the properties window:
The changes I displayed had to do with the fact that CoreScripts can access the property now (where as no scripts could access it before)
You can still set it through the properties window:
The changes I displayed had to do with the fact that CoreScripts can access the property now (where as no scripts could access it before)
Best guess is that the native attribute is behind a fflag and checked is not.
what kind of changes will this make to meshes? is this just lightening the memory usage when meshes collide or will this help make mesh collisions more accurate? I feel the latter has been an unresolved problem for a long time.
Thanks for the correction. As far as I was aware, not even Studio’s property window could modify such high-security properties. Guess I was wrong.
The Roblox Explorer window is not a Lua plugin, it’s part of Studio so it runs on engine level and can modify anything. I heard there was some work on making the explorer a Lua plugin instead and this lighting change might’ve been a part of it (since plugins can’t edit non-scriptable properties)
If it’s a Roblox signed plugin then it can access RobloxScriptSecurity, unsure about the non-scriptable ones. Also, I didn’t mention anything about the explorer.
Sorry, confused the explorer with the property window. Treat “explorer” in my previous reply as the properties panel.
What I meant is that the property panel is not a plugin, it’s a part of the Roblox Studio engine, so it can access non-scriptable properties. A Roblox signed plugin can access RobloxScriptSecurity properties but not non-scriptable ones. So what I meant is that they likely made Lighting.Technology not non-scriptable in preparation for transitioning the properties window to a plugin.
Super happy to hear Player:Move() no longer spams anymore, it makes the dev console unreadable especially for UI only games.
And that dev console server mode command line not working being fixed I’m also happy about, it’s been really frustrating to use.
Apparently the devforum thinks I’ve been writing a reply to this post for several days now. I’m going to leave this reply in the hopes that it stops saying that since no less than 3 separate people have pinged me about it.
Gamepad changes…? Please fix the cursor not appearing when using a gamepad on PC as well as the sensitivity for them. I rely on 144fps to get ideal sensitivity on controller, lower for less speed, because sensitivity on gamepad has been broken for years, not sure how long, but it use to go weeks without being functional at times.
RIP, seems it still thinks so, I’ll ping someone about it.
EDIT: Seems you’re not the only one. Someone will take a look at this next week.
what if you’re just writing a really long post lmao
While you are pinging people, back a month or so ago, someone sent a message to everyone in a group by mistake, then I guess removed all the messages, however, in the dev forums, it still shows I have a message, even though I don’t and its so annoying. Could someone fix this?
Has there been any changes to the physics engine in this update? Our game Hoop Simulator relies on physics for the ball to hit the hoop. We set the ball as massless and set an initial velocity that we calculate is required to hit the hoop. Since this update, the ball is no longer hitting the hoop precisely from long distances, leaving our game completely broken. It has nothing to do with the game itself as the problem persists on older versions.
i remember seeing all of the same errors all over my output and console “Player:Move called, but player currently has no humanoid."
There’s been something I’ve noticed in the past few days when importing 3D meshes and I’m wondering if it may be related to this update. I made a post about it, but in a nutshell, the 3D importer window doesn’t import TGA textured items anymore, yet it was working before the update.
Do you know what’s been up with releases over the past week or two? My servers are on version 633 but clients are still on 631, and 632 should’ve released last week if I’m correct.
Just curious because I’m waiting on a client-sided bug fix that’s scheduled to be turned on shortly after v632.
Edit: 633 is finally out!
The 632 release was skipped with many engineers out for the July 4th holiday, and this week’s 633 release was delayed.
So, expected, but yes, having RCC be two releases ahead is highly unusual, I can’t remember the last time that happened.