Bug - Not A Bug Noodles of Fire and Saucemageddon are class actions

[zarqon]

$skill[Noodles of Fire].class should be Pastamancer, $skill[Saucemageddon].class should be Sauceror.

On a related note, why does skill.class return a string and not a class? Would make more sense as a class, to my thinking.

On another related note (thus making a full chord), I think $skill[Lasagna Bandages].combat should return true. But since there are two versions of this skill, I don't want to make a bug report for that only to have it marked "Not a Bug". Would changing that to true mess up something elsewhere?

 

[Veracity]

7096	Bashing Slam Smash	5	15	0
7097	Turtle of Seven Tails	5	15	0
7098	Noodles of Fire	5	15	0
7099	Saucemageddon	5	35	0
7100	Funk Bluegrass Fusion	5	10	0
7101	Extreme High Note	5	15	0

Note that every one of those is in the 7000's, which is reserved for Item Generated skills. Sure enough, each of them is available only if you have the particular class-specific Nemesis weapon equipped - which is a Quest Item, and thus not available to you unless you really are that class.

Given that 1) it would require special case code and 2) they are NOT "class specific" skills - unless "item generated" is a class- and 3) if you are checking "is class X" to decide if you can cast the skills, that is YOUR bug, since you should be testing "wielding weapon Y" - I don't agree this is a bug.

skill.class should, presumably, return a class - until we decide to make the 7000's return "item" and the 8000's return "bookshelf" or something.

And making Lasagna Bandages would, again, require special case code; we have no internal support for a skill that you can cast both in and out of combat. If we mark it combat, you can't cast it from Use Skills. Contrariwise, if we don't mark it combat, you can't use it in a CCS. I am more sympathetic to special casing this one for the use in consult scripts than I am in special casing the others.

 

[zarqon]

I was thinking of the class field as meaning "you need to be X class to get/use Y skill." I guess I should understand the class field as only applying to permanent skills then. And the 'class' field returning a string is fine if expansion like you mention is planned, but in that case, it should probably be named "source" or somesuch. Needing to do to_class(skill.class) feels really counterintuitive.

I found this while trying to programmatically detect "spells" -- most of them can be easily detected by checking skill.combat && skill.class == Pastamancer|Sauceror, but those two ULEW skills, Lasagna Bandages, Volcanometeor Showeruption, and Hobopolis book spells are the exceptions at the moment (Hobopolis is fairly easy because in the range 28-43 all combat skills are spells, but the other four have to be hard-coded).

Special casing for Lasagna Bandages would be nice, since it would eliminate one of the exceptions.

However, I might just make a feature request for a "spell" proxy field, since the exceptions list is more likely to grow than shrink. Would that be an appropriate field for proxy records?

 

[Veracity]

I was thinking of the class field as meaning "you need to be X class to get/use Y skill." I guess I should understand the class field as only applying to permanent skills then.

I still reject it. It is not the case that "only a sauceror can cast Saucemageddon". It is the case that "only a character wielding the Windsor Pan of the Source can cast Saucemageddon". Now, it just so happens that only a sauceror can get that item, but the item really is the key issue. You can be a sauceror and own the item, but unless you are actively wielding it, the skill is not available to you.

And the 'class' field returning a string is fine if expansion like you mention is planned, but in that case, it should probably be named "source" or somesuch. Needing to do to_class(skill.class) feels really counterintuitive.

Revision 9487

I found this while trying to programmatically detect "spells" -- most of them can be easily detected by checking skill.combat && skill.class == Pastamancer|Sauceror, but those two ULEW skills, Lasagna Bandages, Volcanometeor Showeruption, and Hobopolis book spells are the exceptions at the moment (Hobopolis is fairly easy because in the range 28-43 all combat skills are spells, but the other four have to be hard-coded).

Special casing for Lasagna Bandages would be nice, since it would eliminate one of the exceptions.

If you want $skill[ lasagna bandages ].combat to be true, you need a separate feature request for that, rather than lumping it in with two unrelated issues.

However, I might just make a feature request for a "spell" proxy field, since the exceptions list is more likely to grow than shrink. Would that be an appropriate field for proxy records?

Yes, I suppose.

 

[zarqon]

I can dig it!

Thanks for your swift attention to these requests/questions.