Open androksi opened 2 years ago
In my opinion a server should have no control via scripting on whether to start or stop recording a client's microphone. This would be a concern for players.
If this were to be implemented, the voice recording must be initiated by the client through functionality built into MTA.
A function could be provided, isVoiceRecording
- as well as an event; onClientVoiceRecording
- which contains the audio data.
One final concern would be the server's ability to store/access voice recordings. We'd probably want a function such as requestVoiceAccess
where the client can accept/deny this permission per-server (similar to requestBrowserDomains
).
There should also be a new section in client settings to manage this - again, similar to browser domains.
Lopsi proposal has one flaw: custom server can opt this check
Lopsi proposal has one flaw: custom server can opt this check
How? This is all client-side
if voice data is sent to server, you can not prevent server owner from recording
Thank you, Lopsi! I agree with that. I wonder if it's too difficult to be made.
if voice data is sent to server, you can not prevent server owner from recording
The player is not able to make voice recordings on the server if they do not accept the permission after the scripter uses requestVoiceAccess
. By accepting this, you agree that any voice recordings that you make, may be used by the server.
No voice data is ever sent directly to the server. When a player creates a voice recording, they should have the ability to either accept or delete. This process of creating voice recordings is entirely up to the player and the server cannot interfere (it is built-in MTA client functionality).
Accepting the recording will trigger the clientside event onClientVoiceRecording
and send the audio data, which the scripter can use (as previously agreed to by the player, via requestVoiceAccess
).
I'd like to add as well that it should always be very clear to a user when a voice recording is currently happening. For example through showing an icon that's clearly visible.
Oh, and a way for a user to automatically reject any request for voice recordings if they never desire to make one and want to avoid accidentally triggering one.
Oh, and a way for a user to automatically reject any request for voice recordings if they never desire to make one and want to avoid accidentally triggering one.
Adding to this, it should be clear to the user when a voice access request is accepted or rejected (maybe a 'system' chat message) - regardless of whether they are auto-declining these requests or not.
What is the use case for this? You can use setPlayerVoiceBroadcastTo
for phone system.
What is the use case for this? You can use
setPlayerVoiceBroadcastTo
for phone system.
I meant like WhatsApp, which you can record your voice, then send it, so it will be saved as a file (.mp3) somewhere. Of course this is not the only use case, it's just an idea.
It seems that this is not in the MTA team plans.
It seems that this is not in the MTA team plans.
570
There's nothing in that issue to suggest it's "not in the plans" - this issue is similar/duplicate.
What is the use case for this? You can use
setPlayerVoiceBroadcastTo
for phone system.
As stated, something like audios (voice recordings) for instant messaging. Also logs for RP servers.
Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
A voice recorder would be very useful to those servers which use a phone script, but of course this is not the only point of having such implementation. With that, scripters would be also able to create a bunch of new concepts.
Three functions I found useful would be these;
startVoiceRecording
,stopVoiceRecording
,isVoiceRecording
Also an event:onClientVoiceRecording
, so that we can get the elapsed time and maybe the bytes (I don't really know if it's a bad idea, heavy requests or something else).Also a function to get what's recorded, or... an event
onClientVoiceStopRecording
and one of the parameters would return all the bytes, so we can save it as mp3.It would be really helpful/useful for roleplay servers, specifically those ones which have a phone system.
Describe alternatives you've considered
No response
Additional context
No response
Security Policy