Number of spells per realm requirement

[Therem Harth]

I was messing around with Angband 3.2 today, adding a new spellcasting class (Elementalists, with spellbooks based more or less on the classical elements). Everything went fine until I discovered that the way the spell indexing works seems to require a set number of spells per realm. The number is apparently 64, and Elementlists get only 16...

It *would* be possible to get this working, I think, but it looks like it would require some stupid hackery, testing for the problem realm number and stuff. So before I reimplement the whole thing in a way that doesn't use spellbooks, I have two questions...

1. Is there a non-hacky way to work around this problem in 3.2, without making huge changes?
2. If not, could allowance for magic realms of varying sizes be added to the list of wanted features for the next release? (Assuming it's not too much of a pain to do in C.)

Though FWIW, despite this setback I'm finding it quite fun to work with the current V codebase. It's much less confusing than the other variants I've looked at.

[Nick]

I am currently moving FA to be as like the V3.2 code as I can - and I can't see a way to do that non-hackishly. There is also an assumption built in in places that there are only two spell realms.

FA currently has a big array with all the spells for all the different class types, arranged into books - and I am planning to keep it that way, but in other respects use as much of the V code as possible. The current (seriously under construction) state of FA is here, if you want to look at it for ideas. I have mostly done the spellcasting, I think...

[Therem Harth]

Hmm, thanks.

Looking at this, I think the easiest way to handle the problem is to redo the magic system and divide it up the way I like it. In this case, one tval for spellbooks, five books, eight spells per book, with each book being a separate realm. I think that should work.

[d_m]

If you want to open a bug about making spell/realm/book/magic definitions more flexible I would love to work on that. While I don't expect V (in the short term) to introduce new realms I would like for a variant author to be able to do this easily (via edit files only ideally).

[Nick]

I think new spells are always likely to need more than edit files - but I may be being pessimistic there. And more flexibility is good.

[d_m]

I think new spells are always likely to need more than edit files - but I may be being pessimistic there. And more flexibility is good.

Oh I totally agree that new spell implementations will often need C code (although it'd be nice to be able to parameterize the spells, e.g. Fireball(dmg=100, range=20, radius=2) or something)... but I think that the edit files should support any number of spells/realms/books/whatever.

[will_asher]

What's wrong with do things in hacky ways?

[PowerDiver]

Oh I totally agree that new spell implementations will often need C code (although it'd be nice to be able to parameterize the spells, e.g. Fireball(dmg=100, range=20, radius=2) or something)... but I think that the edit files should support any number of spells/realms/books/whatever.

Ideally, everything would be an effect in effects.c, and the spells would invoke some effect.

The tricky stuff is spells like Orb. You need to define an effective level for invoking the effect, but priests do more evil damage than paladins at the same CL. Perhaps paladins could count as half of a priest for that purpose? That would only work if it made sense to do it consistently across all of the other spells where you want effect to scale with level.

[d_m]

Ideally, everything would be an effect in effects.c, and the spells would invoke some effect.

The tricky stuff is spells like Orb. You need to define an effective level for invoking the effect, but priests do more evil damage than paladins at the same CL. Perhaps paladins could count as half of a priest for that purpose? That would only work if it made sense to do it consistently across all of the other spells where you want effect to scale with level.

My parameterization solution would be to actually have a mapping from generic spells (which would correspond to effects) onto how the spell performs for a given class (in terms of spell power, failure rate, radius, damage, range, chance to beam, whatever). In that case you just need to make sure your effects have the right parameters and you should be able to configure actual spell behavior pretty flexibly.

You could actually define monster attacks in a similar way, mapping a monster attack onto a parameterized effect. The fact that monsters and players are so asymmetric would obviously make that level of code sharing somewhat awkward, but probably not impossible.

[Nick]

The tricky stuff is spells like Orb. You need to define an effective level for invoking the effect, but priests do more evil damage than paladins at the same CL. Perhaps paladins could count as half of a priest for that purpose? That would only work if it made sense to do it consistently across all of the other spells where you want effect to scale with level.

That should be OK - you can just do a check for ZERO_FAIL in the effect definition. More generally, increased use of the player flags to can give more control over this sort of stuff.

[Therem Harth]

What's wrong with do things in hacky ways?

Because the V 3.2 source looks all clean and beautiful, so I would feel guilty about sticking in something that ugly.

Re config files: I don't think that "Migrate realms to config files" should be a goal, just because the code involved in creating new spells is not that tricky to begin with if you're familiar with C's syntax. Also because doing it in C means you can have syntax highlighting, autocompletion, and other nice stuff.

[nppangband]

There is also an assumption built in in places that there are only two spell realms.

It is only a moderate amount of coding to add a new spell realm, and it is fairly straightforward. The hard part is having enough ideas to create a new, balanced, and interesting spellcasting class.

[Pete Mack]

Because the V 3.2 source looks all clean and beautiful, so I would feel guilty about sticking in something that ugly.

Re config files: I don't think that "Migrate realms to config files" should be a goal, just because the code involved in creating new spells is not that tricky to begin with if you're familiar with C's syntax. Also because doing it in C means you can have syntax highlighting, autocompletion, and other nice stuff.

The 3.2 code is hardly clean and beautiful, though it's quite a bit better than 3.0.6.

As for the config files: I don't think anyone is planning to write the spell effects in config files; rather to use them to define the spell books and spell class attributes, as is done in UnAngband. (This makes a lot of sense to me.)

[andrewdoull]

I think new spells are always likely to need more than edit files - but I may be being pessimistic there. And more flexibility is good.

Unangband says you're being unduly pessimistic. 90% of spells 'should' be doable in edit files. However, it does need quite a bit of code refactoring elsewhere to get it done.

Andrew