Wonderful!

I see you are now using nwnx_funcs plugin from maxrock. IMO one of the best additions to nwn (windows version). The possibilities are [almost] unlimited. Too bad that RL doesn't allow me to do any serious work with it...

possible, but difficult:

1) you would have to create different AoEs in vfx_persistent.2da with radius 10', 20', 30' 40' etc.
2) you'd have to modify the AoE-onheartbeat script to destroy the current aoe and activate the next aoe with 10' larger radius
3) you'd have to take care to carry over any spell parameters (dc, metamagic, penetration, casterlevel, location...) from one aoe to the next
4) by the time you destroy the old aoe and create a new (larger) one the association between effects applied by the aoe and the "correct" aoe spellid might be lost. You'd have to take that into account when removing aoe effects (for instance onexit).

I thought about a similar system to implement metamagic enlarge or casterlevel dependent aoe-sizes. Such a system would use some generic aoes of different sizes. The problem with that is, that one needs a generic set of areas (with different sizes) for each different appearance (at least thats my current understanding). Meaning the implementation of metamagic enlarge would require a large nr of "generic" aoes (different sizes, different appearances)

Fluffy is right, as usual.

A new spellcasting system, that reorganizes the spellbook-related 2das, requires a lot more work "under the hood",
than the - relatively straightforward, but tedious - rewriting of the spell-related includes and the spell scripts.

In particular, it is essential that the PRCs automated make process must be functional all the time (one does not
need Stra'ts occasional reprimand to understand that). The PRC make process is not easy to understand. For
instance, the make file is auto-generated, relying on a complex interplay of external programs to auto-generate
the make file. One essential ingredient to that process are several java routines, that extract information from
the source files (*.nss), use it to generate the make-file, and also build the spellbook-related 2das (spells.2da,
feat.2da, iprp_feat.2da), the tlk- entries, and even the manual from a set of "base" 2das. These java routines have
to be partially rewritten, and one has to have a pretty good understanding of the *whole* make process in order to
minimize unwanted side-effects (such as the manual generator screwing up - Fluffy knows about that ).

Without implementing these changes (and properly testing them before updating the PRC's CVS) multiple metamagics
will remain a private project, only. That has been clear to me from the beginning, however, I must admit that I somewhat
underestimated the "additional" work that must be done within the PRC make process.

Prepared metamagic combining is impossible as the spellbook system stands now. (I'm probably the last person on these forums to figure that out.) It could prepare an existing feat of course, but that would be confusing at best.

Its not impossible, but its hard work. And you were on the right track...

The way to do it, is to
- make all (fake) spell casting feats instant feats
- throw out all metamagic fake spell versions (including the quickened fake spells, see below how to handle quickened spells)
- add one metamagic activation (instant) feat for each metamagic (the feat. when activated, toggles the particular metamagic on/off for the next casting)
- change the spellhook (and the spell scripts), so that
    --- all spells go through the spellhook
    --- the spellhook checks the metamagic setting, looks for a valid spontaneous spell slot (or prepared spell) compatible with the metamagic setting
    --- continues the spell or aborts it (if a prepared caster cast a spell with a metamagic combination that he did not memorize)

As fluffy said, I have been developing such a system.

It was 90% finished (it worked in a test environment, however, a lot of 2da work still was left to do).
But then real life kicked in very hard (and the PRC website went down at approximately the same time), so I didn't have any time  to finish it.
Dont have any time now, either.

Basically the only major work I had to do (besides the always required bug-fixing during extended player testing) was to rewrite the java routines that are used to build the PRC fake spell 2da-entries (in feat.2da, spells.2da and iprp_feats.2da). In my test environment I had rebuilt the 2das by hand (for roughly 100 test spells), but in order to have the PRC make process work automatically, the java routines definitely have to be modified. Started to rewrite them, but then RL came in the way.

Here are the features that are working:

- multiple metmagics, including the [not to easy to implement] quicken, silent and still for spont and prep casters (100& tested)
- new metamagics, such as heighten, lasting, permanent, delay, repeat, twin, energy substitution, energy admixture, etc. (100% tested)
- improved spell-capacity, improved metamagic and multispell feats implemented (90% tested)

All necessary includes were up and running. Also all spell scripts were appropriately modified to accept all Bioware and the additional metamagics (except for some "newer" spells scripts mostly added by Tenjac in the last year).

If you are interested, I can send you the stuff. As I said, I currently dont have the time to finish it off, but I would be willing to help, if you are willing to look into it more deeply.

I wanted to include changes allowing quicken to function, but for some reason the game engine was ignoring the metamagic flag at casting.

That is a known limitation of the Bioware provided ActionCastSpellAt* () functions, not only for quicken, but also for silent and still. Another limitation of these functions is, that they don't accept metamagic as a parameter if the cheat-parameter is used. But there are workarounds:
For instance, the way to implement quicken (+still + silent) is to give the caster the autoquicken, autosilent, autostill feat before the fake spell fires. It can be done by an extensive rewrite of the PRC-function ActionCastSpell() in combination with the spellhook. Now, there are some tricky timing issues involved and there is the potential of exploits; however both problems can be handled by - rather extensive - coding and additional checks for exploits.

The advantage of a new metamagic system are (besides the possibility to use multiple metamagics as in Pnp):

- the nr of fake spell entries is dramatically reduced (just one fake spell entry for every "real" spell instead of one entry for every metmagic version)
- the class radial gets a lot less entries
- additional metamagics can be easily added
- new feats, such as improved spell capacity, improved metamagic, multispell etc. are possible, behaving (almost) exactly as the PnP rules

The disadvantages are (obviously)
- extensive rewrite of the includes necessary (not only the x2_inc_spellhook must be changed)
- new java routines necessary for the new fake spell structure (although the new structure is simpler than the old, the routines still have to be written and tested)
- the prc make routine must be changed to reflect the above changes
- some players might not like the process of selecting the metamagic first (by activating the appropriate metamagic feats) and then casting the spell (by activating the spell casting feat). Although once the system is in place, it is fairly easy to customize it, for instance by giving each caster say ~100 customizable feats where they can prepare often used metamagic variants for their spells)

motu99