vgstation-coders / vgstation13

Butts
GNU Affero General Public License v3.0
266 stars 546 forks source link

Speakers won't trigger voice analyzers #32991

Closed D3athrow-Issues closed 9 months ago

D3athrow-Issues commented 2 years ago

(WEB REPORT BY: poales REMOTE: 198.245.63.50:1337)

Revision

Description

Voice analyzers definitely used to be triggered by speakers, but now they aren't.

Steps to Reproduce

Speaker + remote, speaker says "Input" Analyzer + remote, analyzer detects "input"

Use analyzer's frequency on the open wire of a door so you can see output

Say "Input". The door will open

Use the remote signaller on the speaker's frequency. It will say "Input" but the door will not open.

What you Expected

Science

What Actually Happened

basically nothing

Exxion commented 2 years ago

AFAIK voice analyzers have never listened to speakers (at least for several years), and this is intentional to make spambots harder

https://github.com/vgstation-coders/vgstation13/blob/f839452895187cdf64c2996df53002bbcb35f050/code/modules/assembly/voice.dm#L37

Eneocho commented 2 years ago

You can't use em to trigger VAs, but you can still use looped signalers to make the signal pass through.

poales commented 2 years ago

Well that's really disappointing, I wanted to use VAs to produce two signals simultaneously. If you hook up one signaler to send a signal to two signalers they are spaced considerably apart.

Eneocho commented 2 years ago

Use either multiple looped signalers so the signals come at the same tick or use the assembly frames so the signals get sent at the same tick.

poales commented 2 years ago

That's exactly the problem is that the assembly frame DOESN'T send the signals at the exact same time maybe i just need to devise a system whose timing requirements are not so strict

Exxion commented 2 years ago

For the record, this not being a bug doesn't mean that it can't be changed. Completely removing this limitation would make spambots just too easy, but perhaps there could just be a very short cooldown on it rather than speakers always being rejected

This is a rather roundabout way to get the behavior you want, though. There should probably just be an actual intended way to pulse two assemblies at the same time.

Eneocho commented 2 years ago

That's exactly the problem is that the assembly frame DOESN'T send the signals at the exact same time

There should probably just be an actual intended way to pulse two assemblies at the same time.

I finally found my assembly designs file, here's a simple assembly frame design that outputs 2 signals at the same time:

Signaler 1 on hand. (Signal 1)
Signaler 1 on Frame. (Signal 1)
           Linked to Timer 1 (5s)
                    Linked to Signaler 2 (Signal 2)
           Linked to Timer 2 (5s) 
                    Linked to Signaler 3 (Signal 3)

Use Signals 2 and 3 for whatever synchronized effect you want. You can expand this semi-indefinitely adding one extra timer and signaler for each simultaneous signal you want.

Pulse your handheld signaler to start the timers. Make sure they're both on Pulse once and stop mode and to go back to 5s (or whatever time you want). Since timers are linked to gameticks, they'll both start and finish simultaneously, pulsing S2 and S3 at the same time. You can test this by opening a door with signalers, If they're not perfectly synchronized the doors will not open simultaneously.

Here's a frame export of what I used to test it:

signaler||Code+%281+to+100%29=31&Frequency+%28whole+numbers+such+as+1457%29=1455|2;3
timer||Remaining+time=2&Default+time=2&Mode=0&Timing=0|4
timer||Remaining+time=2&Default+time=2&Mode=0&Timing=0|5
signaler||Code+%281+to+100%29=32&Frequency+%28whole+numbers+such+as+1457%29=1455|
signaler||Code+%281+to+100%29=35&Frequency+%28whole+numbers+such+as+1457%29=1407|
Exxion commented 2 years ago

That the timers are required is very strange. I wonder if this is intentional, or if someone just forgot a set waitfor = FALSE or something

EDIT: I actually can't find a delay in my testing, which leads me to suspect it's the latter

EDIT: 100% the latter. Without the timer, execution of the assembly frame is blocked if anything sleeps during the execution of one of the assemblies. So there's no delay if, for example, you have two signalers just trigger speakers or bolt doors or do anything else that takes no time, but there is a delay if, for example, the signalers open airlocks. This should probably be considered a bug.