Bug - Fixed r13248 - NPE in Fern basement

[Fluxxdog]

[9385] Fernswarthy's Basement (Level 139)
Encounter: 11-Dimensional Horror
Round 0: fluxxdog wins initiative!
1 HP costs 0.063μ. ( 4,036 / 4036 )
1 MP costs 8μ. ( 825 / 2846 )
ATT: 2,002 (94% × 98.84, death in 44)
DEF: 2,002 (87.56% × , win in 17020000)
HP: 1,702, Value: 5,639.89 μ, RES: 0
Round 1: fluxxdog casts SAUCEGEYSER!
Round 2: x-dimensional horror takes 5432 damage.
Round 2: fluxxdog wins the fight!
After Battle: Fluxxy shuffles around in his snow suit, helping you find extra stuff.
You gain 3 hit points
You gain 5 Muscularity Points
After Battle: Fluxxy dances a tarantella, summoning not a fearsome tarantula but more items.
After Battle: Fluxxy pulls out some castanets and clicks away, grinning wickedly.
You gain 334 Strengthliness
You gain 149 Wizardliness
You gain 109 Cheek
After Adventure Script skipped for Fernswarthy's Basement
1 HP costs 0.063μ. ( 4,036 / 4036 )
1 MP costs 8μ. ( 806 / 2846 )
ATT: 2,002 (94% × 98.84, death in 44)
DEF: 1,802 (95.45% × , win in 17010000)
HP: 1,701, Value: 5,639.89 μ, RES: 0
Unexpected error, debug log printed.
Script execution aborted (java.lang.NullPointerException): (fight.ash, line 217)
Checkpoints cleared.
Ready for battle!

Line 217 from the mentioned relay script:

			abox.append("<td align=center class='queuecell"+(m == goalmon && count(get_goals()) > 0 ? " goalmon" : "")+(is_banished(m) ? " dimmed" : "")+

Debug log attached.

 

[Darzil]

Try 13251. It looks to me like 'm' isn't successfully matched to a monster, so monster ended up being null, and couldn't pass the name of a null monster to BanishManager.isBanished( monstername ). Now if this happens it returns false instead.

This does suggest to me that the relay script isn't handling 'm' correctly for all monsters.

 

[Fluxxdog]

On further examination, is seems the script in quest has an override of is_banished().

 

[Veracity]

So does this mean this is Not a (KoLmafia) Bug?

 

[Fluxxdog]

I dunno. Can someone completely rewrite a function named the same as an ASH function and have it use their version instead of mafia's? Which takes precedence?

 

[Theraze]

Should that cause an error if you try to rewrite an official function?

 

[Fluxxdog]

Huh, that's a good question. We have a method of introducing functions before they're fully defined, but if we otherwise define duplicate functions in ASH scripts, it throws an error.

int chzbrgr();
...more code...
int chzbrgr(){
Some code that does stuff;}

The above works perfectly fine. Below throws an error.

int chzburgr(){
Some code;}
int chzbrgr(){
Some different code;}

Given the above, the official function is already defined, so logic would seem to say yes, throw the error.

 

[Veracity]

Revision 13266 will not allow a user defined function to override a library function with the same parameters. So, is_banished( monster ) is out, but is_banished( location ) is allowed.

So, for that matter, is is_banished( string ). Considering that you can coerce a monster into a string, that may not be strict enough. Thoughts?

 

[Veracity]

Experimentation reveals that parameter coercion is taken into account for user functions - but it's odd.

boolean foo( string m )
{
    return true;
}

will be called for either foo( "dairy goat" ) or foo( $monster[ dairy goat ] ), since a $monster coerces into a string.

So, what happens if you define:

boolean foo( monster m )
{
    return false;
}

If you put it AFTER the other definition, it works as you might expect:

print( foo( "dairy goat" ) );
true

print( foo( $monster[dairy goat] ) );
false

If you put it BEFORE the other definition, the one with the string parameter is deemed to override the other one and you get a compile error. So, which is wrong?

- If you have both monster and string functions, monsters go to the former and strings go to the latter; monsters never get coerced to strings. That is the behavior if you define the string function first.
- You can't have both a monster and a string function - even though ASH will preferentially choose the function with the strictest parameter type matching. That is the behavior if you define the monster function first.

I think the first is correct. In which case, you SHOULD be allowed to define is_banished( string ) even though is_banished( monster ) is a library function.

 

[Veracity]

And revision 13268 makes it behave that way, both for user-defined and library functions.
I think this is done.