41.78.16 [41.78.16] Player radio messages lack formatting overhead, both player and station radio messages lack formatting in chatlog

[NoelleLavenza]

Formatting such as [col=255,255,255] or *255,255,255* doesn't work over radios, either in overhead messages or in the chat log.

The cause of this is twofold. For the chat log, this appears to be because SayChat.getMessageTextWithPrefix calls ChatUtility.parseStringForChatLog, while RadioChat does not. Notably, this also affects vanilla radio broadcasts, for example ones that use music.

For the overhead messages, it appears to be because RadioChat.showInSpeechBubble doesn't call ChatUtility.parseStringForChatBubble, whereas RangeBasedChat.showInSpeechBubble does. (This is because RadioChat overrides it and doesn't call super, but I'm not entirely sure why the override exists.)
Frequency doesn't show up properly, as -0.1-MHz. You can test it by listening to the AEBS. This is probably because radioChannel defaults to -1, and setRadioChannel isn't called in Radio.AddDeviceText. Even worse, the override that takes a string argument doesn't create a chat message, meaning it cannot be called there, at least not without changing the surrounding code. Frequency now shows up properly, at least.

Also, stationary/placed radio messages don't show up in chat, even if they're from players. Combined with the quick message fade, this makes it almost impossible to use for multiplayer communication.

Finally, handheld radios will automatically turn off if not held in your hand, which makes clipping a walkie-talkie to your belt useless. This makes even handheld radios useless in multiplayer.

Edited June 19, 2023 by NoelleLavenza
Still present in 41.78.16.

[TheSlapDoctor]

Yea there's a lot of weirdness with the radios even after your patch. Seemed to me like being to close to receiving radios makes them stop working, but after further testing it seems like proximity matters less than being in a different room, or maybe not having line of sight?  But even that isn't consistent, if I say 'Hello' while at spot X close to the receiving radio and get no radio response, then try saying 'Hello' at spot Y far away from that same radio, then it still won't work. But if I change to saying 'Testing' without moving from spot Y then the radio will receive it. Possibly something to do with the radios preventing the same message repeated multiple times from showing multiple chat bubbles?

 

Proximity seems to be a factor, but radios will refuse a broadcast for other reasons as well, sometimes not caring about distance to the receiving radio.

 

As for the colours, after a couple restarts I noticed that my radio broadcasts did take my chat colour, and that even radios placed after the restart worked with colour correctly.

[NoelleLavenza]

22 hours ago, TheSlapDoctor said:

As for the colours, after a couple restarts I noticed that my radio broadcasts did take my chat colour, and that even radios placed after the restart worked with colour correctly.

I'm talking about something other than setting the chat color for the entire tab. Specifically, formatting like "*red*red text" doesn't work over the radio, whereas that does work in normal speech. 

[NoelleLavenza]

I can confirm that this is still an issue with the latest patch (41.68).

1) RadioChat uses ChatBase.getMessageTextWithPrefix, which does not call ChatUtility.parseStringForChatLog.

2) WaveSignalDevice.AddDeviceText calls playergetChatElement().addChatLine with boolean arguments true, true, true, false, false, true. The fourth false means that allowColors is false. This means that color formatting that works fine in normal speech will fail over the radio.

3) IsoWaveSignal.AddDeviceText never calls showRadioMessage, even for player messages.

4) Broadcast messages sent by RadioChannel.update will not have their author set properly (since it overwrites it with getChatOwnerName()), resulting in radio messages having incorrect authorship info.

The solution to #1 is obvious.

The solution to #2 would require either stripping color tags from messages broadcast over the radio (more difficult, but would make it easier to distinguish from normal spoken text), or simply setting allowColor to true (change the fourth boolean argument to true).

The solution to #3 would be to use the corresponding code from WaveSignalDevice.AddDeviceText.

The solution to #4 is probably to use the currently-unused helper, RadioChat.createBroadcastingMessage, ChatManager.createRadiostationMessage, or ChatServer.createRadiostationMessage, which does handle setting authorship. Then, sendToServer would handle broadcasting it, while keeping authorship information intact. (There is a nonzero chance that it might fail once again in AddDeviceText due to ChatManager.getInstance().showRadioMessage being called, which removes the authorship information by recreating the message from scratch. Either way, this fix would be a great improvement over it not working at all.)

[NoelleLavenza]

This is still an issue in multiplayer in 41.78.16. Radio broadcasts with `music` will not display properly in chat.