I noticed that AudioEmitters don’t actually make sound in 3D space, but AudioListeners do hear them.
Assuming that will be fixed, I also hoped that Sounds could be heard by AudioListeners. For some reason, this makes me believe that converting all sounds to AudioEmitter would be a bad idea due to higher memory usage.
Also, no AudioPanner? 
It also says Camera and PVInstance. I put it under a part, which is a PVInstance!
Oh my bad, I also tested it out under a part and it indeed is silent.
aint this still a disabled flag that you have to enable with the mod manager? also isnt the api like… unfinished or something? stuff sometimes doesnt work
I have no idea, but some stuff don’t work and I’m on the LIVE version of Studio
Could this Secret thing help out with client anti-cheats?
Can’t define a string as a SharedString either (maybe you should be able to? 
) but that’s never stopped them from being a pain for a select few people!
I should’ve come here earlier since I didn’t even know about these, but yeah they’re live. At least in the sense they do in fact work in Live games.
Secret is supposed to be there for ServerSide code
for example you define webhook link as a Secret and then that secret is actually on roblox’s dashboard
then when you want to use that webhook this is what you would do on the server (of course that feature is not avalivable yet so im guessing how it would work)
game:GetService("HttpService"):PostAsync(Secret,data)--Secret is webhook link and data is JSON string
thank you! Hopefully we will get some more news on hyperion soon!
They derive from the same type but they aren’t the same thing. Bytecode, ProtectedString and BinaryString are three different things.
It’s the same thing most developers do:
type Milliseconds = number
type Seconds = number
local function toMS(time: Seconds): Milliseconds
end
This makes it easier to understand code behavior.
Hey blueberry; sorry for the late reply! Didn’t see these comments
I noticed that AudioEmitters don’t actually make sound in 3D space, but AudioListeners do hear them.
If you create an AudioEmitter under one part and an AudioListener under another, the listener hears the emitter, and you can Wire the listener’s output to another instance (e.x. an AudioDeviceOutput) to get access to what it hears – if you don’t wire up the Listener’s output, it’s like emitting into the void 
For some reason, this makes me believe that converting all sounds to AudioEmitter would be a bad idea due to higher memory usage.
AudioEmitter only implements part of Sound’s functionality; if you Wire one AudioPlayer to one AudioEmitter, it should be comparable, memory-wise. Wiring one AudioPlayer to multiple AudioEmitters, or multiple AudioPlayers to one AudioEmitter uses less memory than duplicating Sounds
Also, no AudioPanner?
Panning is a special case of Emitters + Listeners; with some math, you should be able to implement a panner 
So an AudioDeviceOutput placed anywhere will have audio panning because of the camera and the position of the emitter in 3D space? Or will it play the same everywhere? Because that’s what I’m imagining.
AudioDeviceOutput sends whatever it receives directly to your system out, such as headphones or speakers; it doesn’t do any panning on its own, but if you set something up like this:
Then whenever the AudioPlayer is Play()ed:
AudioEmitter
AudioEmitter broadcasts the stream out into the world from Part.Position
AudioListener hears the stream from the perspective of Camera
AudioListener sends what it heard to AudioDeviceOutput
In the future, can we use Wires for literally anything? I have a similar modular wiring system in my own game with models, and it would be nice to use a literal Wire instead of ObjectValues! Also, would we ever be able to do something like this:
AudioReverb:GetWireConnections() -->
{
Wire named 'FromAudioPlayer',
Wire named 'ToOutput'
}
A :GetWireConnections(), or :GetWires() function to return all the wires which pass in and out of any audio module. Or even as I said above, any instance. I’m assuming the system already knows this, but maybe not. It would help me out if it could be used with any instance!
At the moment wires only carry audio streams – generalizing is something we’ve discussed though
With respect to
A
:GetWireConnections(), or:GetWires()function to return all the wires which pass in and out of any audio module
would you mostly be interested in this for plugin/offline usage, or do you have use-cases in mind that need this information at runtime? You might be able to use CollectionService/tags to accomplish some of the same behavior
Please feel free to file feature-requests surrounding these!
The game I was referring to uses ‘electronic components’ like a button, conveyor, and a motor. I wire the button to the motor, indicating that the motor will only turn if the button’s wire is activated. These wires are simply just ObjectValues, and some logic in modules that handle them. It would be beneficial if I could, assuming we can set TargetInstance, SourceInstance to anything:
OnServerInvoke in RemoteEvents, to determine if a connection is valid. This would return a boolean and it will set the Activated property, so long as the two objects are not valid audio modules (they will always be activated and it won’t ask the callback if it should activate).:Fire(data), :Invoke(data), :Send(data), etc.WireConnected(wire) event, with an opposing WireDisconnected(wire) event, to tell instances if they’ve been connected and the wire is now activated:GetWireConnections(): {Wire} method to get all the wires that are connected to the objectThe :GetWireConnections() method could of course be made manually in scripts by listening to DescendantAdded, but I’d like if we didn’t have to use a hacky method like that to get the wires!
All of this would greatly benefit my system, and I know a lot of other games could benefit. Mainly thinking of building games who set up levers or buttons to activate something like a cannon or a light.
It’s a huge(ish) ask though, and it’s not extremely important at the moment! 
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.