Feature: This PR reduces message log spam from ships with not enough crew.
Rather verbose writeup as it's also PR'd to ESC
Feature Details
The <ship> is moving erratically because you do not have enough crew to pilot it. messages have been marked as unimportant, so they will not redisplay at the bottom of the screen until they are cleared from the message queue - that is, after about 17 seconds, or sooner if there are many messages from other sources coming in.
In practise, a message from a severely shorthanded vessel will still be shown at almost all times, but it will not compete with other messages for display in the queue, and it will scroll up in an orderly fashion.
Reasoning
In the current game, when one captures a ship and is either severely shorthanded as a result or there are many captured ships, the message log quickly becomes flooded with complaints that there are not enough crew - up to one per ship every half second - drowning out all other messages. While perhaps realistic - there may not be enough crew members to handle communications - this is extremely annoying and detracts from gameplay, as the player may easily miss more important messages.
Describe alternatives you've considered
I've also tried and tested adding a cooldown to the messages that is only as long as it takes for a message to fade (about 10 seconds, which is shorter than the time it takes for a message to be erased from the queue). Although it worked, that method required adding more lines of code; this PR's method is much simpler.
If we wanted to retain a nod to realism, I could instead only mark escort ships' complaints as unimportant. This would still disrupt your communications when your flagship is short-handed, but at least escorts would not do this to you. My preference however is to mark all such messages as unimportant as this PR does currently.
Testing Done
Capturing a ship and then basking in the newfound readability of the message log.
Performance Impact
If anything I'd expect this to be mildly positive.
kikotheexile
commented
3 years ago
Feature: This PR reduces message log spam from ships with not enough crew. Rather verbose writeup as it's also PR'd to ESC
Feature Details
The
<ship> is moving erratically because you do not have enough crew to pilot it.messages have been marked as unimportant, so they will not redisplay at the bottom of the screen until they are cleared from the message queue - that is, after about 17 seconds, or sooner if there are many messages from other sources coming in.In practise, a message from a severely shorthanded vessel will still be shown at almost all times, but it will not compete with other messages for display in the queue, and it will scroll up in an orderly fashion.
Reasoning In the current game, when one captures a ship and is either severely shorthanded as a result or there are many captured ships, the message log quickly becomes flooded with complaints that there are not enough crew - up to one per ship every half second - drowning out all other messages. While perhaps realistic - there may not be enough crew members to handle communications - this is extremely annoying and detracts from gameplay, as the player may easily miss more important messages.
Describe alternatives you've considered
I've also tried and tested adding a cooldown to the messages that is only as long as it takes for a message to fade (about 10 seconds, which is shorter than the time it takes for a message to be erased from the queue). Although it worked, that method required adding more lines of code; this PR's method is much simpler.
If we wanted to retain a nod to realism, I could instead only mark escort ships' complaints as unimportant. This would still disrupt your communications when your flagship is short-handed, but at least escorts would not do this to you. My preference however is to mark all such messages as unimportant as this PR does currently.
Testing Done
Capturing a ship and then basking in the newfound readability of the message log.
Performance Impact
If anything I'd expect this to be mildly positive.