apollo-rsps/apollo

Add a VerificationHandler for MagicOnMob messages

Opened this issue · 6 comments

Major- commented

Can be implemented just like the other ones (e.g. NpcActionVerificationHandler).

Need to check:

  • The Mob exists (i.e. index is valid)
  • Type of the Mob matches the Mob at the index

Combat stuff to also consider:

  • Mob can be attacked/have the spell cast on them (can this be done from the handler?)
  • The spell is valid (can this be done from the handler?)
  • Spell is from the magic book the player currently has open

cc @garyttierney for thoughts on the combat bit

Promises commented

might as well verify magic book?

  • 👍1
garyttierney commented

@Major- I believe that you can check 1) the spell is valid 2) the spell is from the magic book the player currently has open if we start loading widget data and check a players current InterfaceSet. Avoiding that, it'd need to be plugin specific logic.

Tomm0017 commented

To check if the player can be attacked, the handler would need access to https://github.com/apollo-rsps/apollo/blob/kotlin-experiments/game/plugin/entity/actions/src/playerAction.kt#L27. Would it be okay to move the Player.actions to the Player class?

garyttierney commented

No, that wouldn't be the correct approach. The correct thing to do here would be having the magic plugin depend on player-actions and calling Player.actionEnabled(). Plugins export their public APIs for consumption by other plugins.

  • 👍1
Tomm0017 commented

No, that wouldn't be the correct approach. The correct thing to do here would be having the magic plugin depend on player-actions and calling Player.actionEnabled(). Plugins export their public APIs for consumption by other plugins.

Good to know. Was basing it off the request in OP.

Mob can be attacked/have the spell cast on them (can this be done from the handler?)

I'll make the handler include the initial two points in OP and leave the combat bits for plugins

garyttierney commented

I suppose this one is actually a bit more nuanced than a typical verification handler that checks "core" preconditions. @Major- what are your thoughts on that? I don't think that plugin code should be bleeding into something as core as the verification handler.

edit: and actually, I'm not even sure if that's possible.