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

Make handling of arbitrary message sources more flexible #6310

Open
naomimyselfandi opened this issue Aug 21, 2024 · 2 comments
Open

Make handling of arbitrary message sources more flexible #6310

naomimyselfandi opened this issue Aug 21, 2024 · 2 comments
Labels
discussion This issue has (or wants) a discussion enhancement A new feature or upgrade of an existing feature to add additional functionality.

Comments

@naomimyselfandi
Copy link
Contributor

naomimyselfandi commented Aug 21, 2024

Some messages can come from an arbitrary source: Check 6, Player Dead, (High) Praise, and Arrive Enemy are the main ones. Currently, Arrive Enemy has a hardcoded check for whether it should be sent from Command; the others can only come from wingmates. There's no technical reason why this should be, and Arrive Enemy messages could add some nice flavor to warships (as well as finally giving large personae a real use case).

I'm visualizing a new algorithm which (message_send_builtin_from_whoever) which is used to send messages from arbitrary sources. This algorithm starts by choosing one of three "modes" to run in:

  • In command mode, the message's source is #Command.
  • In wingmate mode, a random wingmate is chosen as the source, using the existing ship_get_random_player_wing_ship(SHIP_GET_UNSILENCED) algorithm.
  • In capital ship mode, a random unsilenced ship with a capital ship persona assigned is chosen.

The choice of which mode to use is random with a configurable probability distribution. The default for command mode and capital ship mode is 25%, unless no personae of the given type are defined, in which case the default is 0%. (See below.) These can be configured with $Chance for Command to send messages: and $Chance for capital ships to send messages:; the existing existing $Chance for Command to announce enemy arrival: setting in messages.tbl will be kept as an obsolete synonym, but issue a warning.

If a message source appropriate for the chosen mode can be chosen, that source attempts to send the message. If a source cannot be chosen (e.g. because capital ship mode was chosen, but there are no capital ships in the mission), or if the chosen source fails to send the message (perhaps because it is silenced or has an incomplete persona), this algorithm repeats, excluding the chosen mode. If it fails a second time, it repeats once more using the final unchosen mode.

This behavior is equivalent to the existing behavior unless a command or capital ship persona is given previously unsupported message types. Of particular note is the requirement that a capital ship needs to have a capital ship persona before it can send builtin messages. This implicitly prevents capital ships from being automatically assigned personae: without at least one capital ship persona defined, automatic assignment will give them wingmate personae, which would be bad. It also ensures that a capital ship which is automatically assigned a wingmate persona due to receiving orders will not become eligible for automatic messages.

If there's any desire for it, this algorithm could be extended to include support ships.

@MjnMixael
Copy link
Contributor

The first thing I'm gonna ask for when this feature exists is a sexp to be able to set those probabilities mid-mission.

@wookieejedi wookieejedi added enhancement A new feature or upgrade of an existing feature to add additional functionality. discussion This issue has (or wants) a discussion labels Aug 21, 2024
@wookieejedi
Copy link
Member

All of that sounds very useful and logical to me, thanks for writing such a detailed plan!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This issue has (or wants) a discussion enhancement A new feature or upgrade of an existing feature to add additional functionality.
Projects
None yet
Development

No branches or pull requests

3 participants