I guess that is a fair case to have it as it’s own separate type, but really if you are sending secrets to the client that should be the developers problem. But I guess just like how some APIs will invalidate your cookies when detected on GitHub it is helpful for people who don’t know what they are doing.
Everyone makes mistakes, even the best of us. It’d be a nice to have just in case you accidentally slip up somewhere. I think it’s possible for it to still leak since you’d probably need to be able to place it into a normal string, but maybe it’ll help reduce possibilities of leaks. Either way, it’s not really a big deal that it was added.
Indeed its not a big deal, just always wanting to know how the language I use every day is changing.
Adds PS4 to the list of available devices in emulator.
Yes . That’s all I wanna say right now
Woah…
Wait. Could you explain this one, whichever staff knows? Is that what I think it is? It’s too good to be true if that’s what it is… so it can’t be. Is it?
(hasn’t worked):
Forgot this was even a thing, and I think that’s a good thing. It’s really not nice on performance or technology to have specific collisions forced every single frame. Feels almost surreal to think there was a time where you had to forcefully override these every frame, and now you don’t.
See: Opening Keynotes - RDC23 @ 2:09:06 - 2:09:37 and Accelerated Creation: Studio, AI and In-Experience - RDC23 @ 10:08 - 10:24
Absolutely big w’s to the person who fixed the vc/camera icons. They looked hideous before, but now look clean and nice!
Also, is Live Scripting what I think it is?
Scripting like its Google Docs share feature?
To be fair, the script Source
property is locked during runtime. Unlocking it would imply that you can modify existing lua bytecode, which is plain difficult if not impossible.
But having something to script during a game without using, say, loadstring
, would be very useful.
So that you can’t look inside it, because it’s secret. If it were a string you could just print it to the output!
Consider something like header = "Authorization: Bearer " .. secret
yielding a new secret to pass to Roblox APIs without revealing the value to the programmer.
We could have just used a string but we figured we could take advantage of the sandboxed nature of the platform to do better.
May be a stretch, but is this going to be used in DynamicImages in any way? I was thinking that you should be able to read the screen image data but not be able to understand it for security purposes. Could be completely wrong though.
Quick question about this pending item:
The Avatar Previewer now alerts you if warnings will prevent you from uploading the previewed avatar to the Marketplace.
Does the warning part pertain to a pre-moderation review, or more of a warning of mechanical issues with the item?
I was wondering too, I’ve seen the documentation for it and I’m quite excited for the changes. Especially for the multiple 3D sources of sound, and the new “AudioAnalyzer” instance which should make audio visualizations way more interesting. I’ve already seen your video on it on an earlier release note.
On another note to staff; I was wondering if this would replace existing Sound instances by deprecation, or if both methods would still be available? Also, will there be more effects/deeper controls on audio effects in the future?
The Avatar Previewer now alerts you if warnings will prevent you from uploading the previewed avatar to the Marketplace.
Now add notes for whenever your item gets rejected
It’s not really “live” but you can add it with Instance.new()
in the command bar. I even made my own visualizer with it
Yep! I got to try it and it’s honestly pretty cool watching others code in real-time with their labels flying around. I didn’t get to see how undo/redo works though so I’m interested to try it again once it becomes a Beta feature.
If you’re talking about the Script Profiler fix, there’s nothing internal about it, you can use it from the Developer Console and all the functions mentioned are now displayed.
It’s not like the existence of upcoming AudioAnalyzer instance is a secret.
So is the AudioPlayer an advanced Sound object? Or do you have to ‘wire’ things up to a normal Sound?
The AudioPlayer is similar to a sound, however it sends a audio stream when wired to a audio class with an input pin. The audioplayer basically has every property of Sound except for a few such as volume and playbackloudness (I assume could be added in the future when it’s released fully). It also has :Play() and :Stop() as its only functions. Playing a audioplayer by itself will not project audio or project audio in the 3D space (AudioEmitters do that), it will only project a audio stream.
I wouldn’t call AudioPlayer a advanced sound object, but rather the base of what you connect it with using Wires.
Here’s how it worked with my visualizer.
AudioPlayer → Wire → AudioDeviceOutput: Sends a audio stream from the AudioPlayer to the output audio devices such as headphones, etc.
AudioPlayer → Wire → AudioAnalyzer: Analyzes each audio buffer and information is receivable through :GetSpectrum() which returns a frequency spectrum through a table of numbers
There’s a lot more you can do with Wire but the point of the new Audio classes is that it allows you to customize where your audio outputs, what inputs and what and where the effects are (e.g fade)
AudioPlayer | Documentation - Roblox Creator Hub AudioAnalyzer | Documentation - Roblox Creator Hub Wire | Documentation - Roblox Creator Hub (edited)
Sounds like a great topic idea for #resources:community-tutorials! Maybe I’ll make it! Once I figure this out…