Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove or redesign "ghost" messages #972

Open
TrickyLeifa opened this issue May 23, 2024 · 2 comments
Open

Remove or redesign "ghost" messages #972

TrickyLeifa opened this issue May 23, 2024 · 2 comments
Assignees
Labels
bug Confirmed bug DOOM#% Something is doomed to be destroyed engine/timing Issues related to event timing and sequencing (not lag-related issues) exploit This issue causes an exploit hack ui Issues related to the user interface (non-viewport related)

Comments

@TrickyLeifa
Copy link
Contributor

Ghost messages are a "feature" that was recently added, unfortunately this "feature" also exemplify a good deal of why it is very poorly designed. First is code complexity, the amount of code that was changed (especially logs) to accommodate the supposed feature is a cruel mistake. The code is very shoddy and so poorly implemented you have to use a magnifying glass and a PHD in natural science to figure out the intention of some of it.

The very fact that the 'Instant Objection' toggle can completely bypass the ghost message is horrendous. Additionally, the fact there can be multiples ghost messages queued after another, which completely defeats the purpose of the system which is meant to relay to the user that ONE other user already spoke and that their message is on the way is idiotic at best and completely insane at worst. If everyone can queue their message anyway with a system that is meant to control the flow of messages it's completely and utterly useless.

@TrickyLeifa TrickyLeifa added bug Confirmed bug engine/timing Issues related to event timing and sequencing (not lag-related issues) ui Issues related to the user interface (non-viewport related) exploit This issue causes an exploit hack labels May 23, 2024
@TrickyLeifa TrickyLeifa self-assigned this May 23, 2024
@in1tiate in1tiate added the DOOM#% Something is doomed to be destroyed label May 23, 2024
@collinxchu
Copy link
Contributor

collinxchu commented Jun 21, 2024

Personally, I would redesign it to work like so:

Messages are coming in to the client > The client types a message and hits enter > Text input is disabled/greyed out/otherwise made clear you cannot hit enter again > Client waits for their SINGLE message to be processed > Text input is enabled/not greyed/etc.

This preserves the "you don't have to hold down enter" behavior, keeps the incoming queue, and solves the issue of compounding chat noise via multiple outbound messages.

@stonedDiscord
Copy link
Member

I vote remove

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bug DOOM#% Something is doomed to be destroyed engine/timing Issues related to event timing and sequencing (not lag-related issues) exploit This issue causes an exploit hack ui Issues related to the user interface (non-viewport related)
Projects
None yet
Development

No branches or pull requests

4 participants