Lion/Lion_II LUA's canCast check is against the other version's spell?

[RAIST5150]

I affirm:

• [x] I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
• [x] I have read and understood the Contributing Guide and the Code of Conduct.
• [x] I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.

OS / platform the server is running (if known)

Playing on XiOmi web (Windows 10 I think?), but this is something spotted in LSB base code

Branch affected by issue

base

Steps to reproduce

This was not something actively experienced in game yet, but could pose a potential problem. I was looking for an answer to a question about these trust AI's asked in Discord and noticed this discrepency in their LUA files.

Lion checks if canCast Lion_II spell

Lion_II checks if canCast Lion spell

Expected behavior

They check against thier respective spells.

[RAIST5150]

scripts/actions/spells/trust/lion_ii.lua

-- Trust: Lion II
-----------------------------------
local spellObject = {}

spellObject.onMagicCastingCheck = function(caster, target, spell)
    return xi.trust.canCast(caster, spell, xi.magic.spell.LION)
end

scripts/actions/spells/trust/lion.lua

-----------------------------------
-- Trust: Lion
-----------------------------------
local spellObject = {}

spellObject.onMagicCastingCheck = function(caster, target, spell)
    return xi.trust.canCast(caster, spell, xi.magic.spell.LION_II)
end

spellObject.onSpellCast = function(caster, target, spell)
    return xi.trust.spawn(caster, spell)
end

[mogulbgod]

I think it's to check if the other version of said trust is summoned. You can't summon both versions of Lion (or other similar I/II trusts).

[RAIST5150]

Guess that makes sense... early on we could get away with casting each version at the same time.

It looked odd to reference a different spell... like it could have easily been a typo.

Can't verify if there is any impact when you have both spells in your list. So figured I'd put it out there...either it needs to be fixed, or perhaps it is documented to not be an issue if it gets questioned in the future.

[mogulbgod]

Guess that makes sense... early on we could get away with casting each version at the same time.

It looked odd to reference a different spell... like it could have easily been a typo.

Can't verify if there is any impact when you have both spells in your list. So figured I'd put it out there...either it needs to be fixed, or perhaps it is documented to not be an issue if it gets questioned in the future.

I think the function is just worded strange for what it does right there. You can have the spells themselves in your spells list but not the summons active at the same time (if you get on an instance that you have commands available you can run !alltrusts and you'll have them all in your list) . This is how I remember it on retail. Also if you look at the other trusts like Tenzen I and II they also have the same check.

[cocosolos]

The third param for xi.trust.canCast is optional. You can pass it an ID or a table of IDs of other trusts that can't coexist. If you look at other trust files they don't use this param because the trust you're casting is always automatically checked first.

[zach2good]

Driveby: This is by design. That argument is the ID or table of IDs of Trusts that the current Trust isn't allowed to be summoned alongside.

https://github.com/LandSandBoat/server/blob/base/scripts/globals/trust.lua#L270