Currently Effect Name is used to look up effects internally. As a result we cannot handle effects with matching names, of which there are several.
EffectId is exposed whenever we encounter Effects, so they should be easy to handle there. In database files we will handle them as we currently do items, so if name is unique, we'll use name, if not unique we can use [xxxx]Name where xxxx is the Effect ID, to disambiguate them. [xxxx] will also be usable in ash scripts for specificity, or [name] will continue to work on a best endeavours basis.
First step, in r15508, is to make AdventureResult work with effectID constructors, and EffectDatabase to allow all lookups by effectId.
Next steps will involve going through anywhere using those constructors, comparions, lookups etc to prefer effectId, but work with effectName.
Then datafiles will be updated to use [xxxx]Name for ambiguous effects, and custom code for doing that job, or commenting out of things we can't handle, will be removed.
Something that started bugging me whilst doing r15508 was that we currently construct AdventureResults in one of two ways :
AdventureResult AUDITORS_BADGE = ItemPool.get( ItemPool.AUDITORS_BADGE, 1 );
AdventureResult AUDITORS_BADGE = new AdventureResult( ItemPool.AUDITORS_BADGE, 1, false );
Is there any good reason I shouldn't change them all to the ItemPool.get variant, or is the second preferred. Whilst I'm going through this I might as well make things consistent.
I could also create EffectPool.get( EffectPool.EFFECT, turns ) and use that for all Effect AdventureResults for consistency. Could then get rid of Effect enum section also.
Thoughts ?
EffectId is exposed whenever we encounter Effects, so they should be easy to handle there. In database files we will handle them as we currently do items, so if name is unique, we'll use name, if not unique we can use [xxxx]Name where xxxx is the Effect ID, to disambiguate them. [xxxx] will also be usable in ash scripts for specificity, or [name] will continue to work on a best endeavours basis.
First step, in r15508, is to make AdventureResult work with effectID constructors, and EffectDatabase to allow all lookups by effectId.
Next steps will involve going through anywhere using those constructors, comparions, lookups etc to prefer effectId, but work with effectName.
Then datafiles will be updated to use [xxxx]Name for ambiguous effects, and custom code for doing that job, or commenting out of things we can't handle, will be removed.
Something that started bugging me whilst doing r15508 was that we currently construct AdventureResults in one of two ways :
AdventureResult AUDITORS_BADGE = ItemPool.get( ItemPool.AUDITORS_BADGE, 1 );
AdventureResult AUDITORS_BADGE = new AdventureResult( ItemPool.AUDITORS_BADGE, 1, false );
Is there any good reason I shouldn't change them all to the ItemPool.get variant, or is the second preferred. Whilst I'm going through this I might as well make things consistent.
I could also create EffectPool.get( EffectPool.EFFECT, turns ) and use that for all Effect AdventureResults for consistency. Could then get rid of Effect enum section also.
Thoughts ?
Last edited: