Don't have my full 8 casts of Epic Magic

MannyJabrielle wrote:The way I'm seeing it is that at the high end, the wizard class will still suffer the same essential problem under the current AEMS beta of their epic spellcraft numbers being less than the equivolent druid/sorc/cleric caster, only by design, not by bug.

Even without the Aenea goodies like tomes and the XP store, just the default NWN mechanics, the wizard can go over the 127 cap on spellcraft, and the simpler forumla of -int modifier/+2x casting stat modifier will put the wizard at a lower score than a sorcerer or cleric with the exact same setup.

It's not a HUGE difference, but it is still a loss for wizards, particularly the end end ones, and that's where the wizard class should start to outshine the other casters if anything else, not start lagging behind

OK, I want to make sure I'm following, because this is a complex train of thought, and if we misunderstand, then we aren't discussing the same things and waste each others' time.

So, I get that with Vagabond's workaround, A wizard who goes over the 127 cap will lose some of the benefit of some (indeterminable) bonuses when the INT mod is subtracted and re-added and the custom script forces the result for all PCs to be no more than 127. It means a non-wizard who normally would not hit the 127 cap with their INT mod, might go over the 127 cap when their INT is subtracted and their casting stat is added instead, but then they would still be subject to the proposed forced cap of 127 in the custom script.

This levels the playing field in regards to the cap, and makes it so non-wizards with equal casting stat to a wizard do not end up with a greater bonus than said wizard due to the cap.

If the cap did not exist, and wizards got their full uncapped bonus, then non-wizards would still need their int mod subtracted before casting stat mod was added in order to keep things level between classes, or am I wrong? I am thinking it would be no good to give non-wizards the int bonus plus casting stat bonus combined, even if there was no cap.

So with Vagabond's workaround, I guess I am not quite seeing how high-end Wizards might lose more to that forced 127 cap in the proposed custom script than non-wizards (with equivalent casting mod investment) whose int mod is subtracted before casting mod is added?

Wiard 1 had 108 spellcraft without casting mod, and an Int mod of 30. Cleric 1 has a spellcraft of 108 without casting mod, Int mod of 15 and a WIS mod of 30.

Custom script for Wizard 1 gets 127 total spellcraft, subtracts 30 int mod to get 97, then re-adds 30 int mod to get 127.

Custom script for Cleric 1 gets 123 total spellcraft, subtracts 15 int mod to get 108, then adds 30 Wis mod to get 138, but then force caps the result to 127 to make it even with the Wizard.

Both PCs now have a value of 127 spellcraft to which they get their stat mod added, which brings both to 157.

This result looks to me like it is fair, but I have this feeling that Manny is seeing something we are missing, and I want very much to see it, too.

So lets take the same two PCs and examine the results of using Manny's proposed onEquip and onUnequip scripting to get an accurate value for the enhancement bonuses.

Since both PCs have a 108 spellcraft without casting mod, we already know they have +50 enhancement from various sources.

So, Manny's scripting has that +50 value stored in a variable for both PCs.

Now, we have a script that gets the base ranks (43 for both PCs), the feat bonuses (+15 for both PCs), the enhancement variable from the equip scripting (+50 for both PCs) and lastly the casting stat mod  (+30 for both PCs).

Both PCs end up with 138 spellcraft. In this scenario both ideas seem to work OK, so I am suspecting that the issue Manny sees has to do with a scenario where both PCs do not have equivalanet bonuses, and the non-wizard will come out on top with Vagabond's custom script that uses the 127 forced cap calculation.

Is this making sense, Manny? I know you're way better at scripting than I am, and I want to understand the issue better. Can you help me?

daveyeisley wrote:

So, I get that with Vagabond's workaround, A wizard who goes over the 127 cap will lose some of the benefit of some (indeterminable) bonuses when the INT mod is subtracted and re-added and the custom script forces the result for all PCs to be no more than 127. It means a non-wizard who normally would not hit the 127 cap with their INT mod, might go over the 127 cap when their INT is subtracted and their casting stat is added instead, but then they would still be subject to the proposed forced cap of 127 in the custom script.

Not exactly... the non-wizard epic caster would only get their numbers mucked up if their intelligence modifier is 20 or higher and they are toting +50 in spellcraft+X gear and/or spell effects increasing spellcraft (iouns, focus, ascension bonus, ect). 

Whether or not the character is a wizard is actually rather inconsequential overall, it's the mechanics of getting the accurate spellcraft score with full modifiers.  Wizards will encounter the problem sooner and more often because they do use INT for their spellcasting.  Non-wizards with higher int scores will run into this as well.

Dave wrote:

This levels the playing field in regards to the cap, and makes it so non-wizards with equal casting stat to a wizard do not end up with a greater bonus than said wizard due to the cap.

Correct.... or rather more accurately, it levels the playing field by making sure wizards do not get less than they should.

If the cap did not exist, and wizards got their full uncapped bonus, then non-wizards would still need their int mod subtracted before casting stat mod was added in order to keep things level between classes, or am I wrong?  I am thinking it would be no good to give non-wizards the int bonus plus casting stat bonus combined, even if there was no cap.

Correct.  Whether or not the formula subtracts int and then add casting stat, or does not subtract in but adds casting stat (adding int two times for wizards) is inconsequential to the scripting limitations.  Either way, high-int PCs will get flubbed numbers be they wizards or non-wizards.

It's not a question of "well should wizards get same or more or less, it's a question of scripting/engine limitations which foul up the numbers.

So with Vagabond's workaround, I guess I am not quite seeing how high-end Wizards might lose more to that forced 127 cap in the proposed custom script than non-wizards (with equivalent casting mod investment) whose int mod is subtracted before casting mod is added?

It does not account for the scripting limitations+engine cap issue.

Wiard 1 had 108 spellcraft without casting mod, and an Int mod of 30. Cleric 1 has a spellcraft of 108 without casting mod, Int mod of 15 and a WIS mod of 30.

Custom script for Wizard 1 gets 127 total spellcraft, subtracts 30 int mod to get 97, then re-adds 30 int mod to get 127.

Custom script for Cleric 1 gets 123 total spellcraft, subtracts 15 int mod to get 108, then adds 30 Wis mod to get 138, but then force caps the result to 127 to make it even with the Wizard.

Both PCs now have a value of 127 spellcraft to which they get their stat mod added, which brings both to 157. 

This result looks to me like it is fair, but I have this feeling that Manny is seeing something we are missing, and I want very much to see it, too.

The "getskillrank" fuction has two possible outcomes.  base skill score, or base skill score +modifiers.  It does not separate the ability modifier from all other modifiers (feats, items, ect).  This turns into an issue on subtracting the int modifier when the spellcraft score is above 127.

To put it in a simpler algebraic form, B= base ranks.  M= non-ability modifiers, such as feats, items, ect.  A= Int modifier. A2= Casting stat modifier (int, cha, or wis depending on class)  X is the target number we are looking/solving for.

The getskillrank function would then be either  X=B (base skill ranks, no modifiers) or X=B+M+A.  The "getabilitymodifier" function would return "A".  There is no single script function for obtaining M, as M is an array of feats, item properties, and spell effects.

So....

X= ((B+M+A)-A)+(A2)

For a wizard with 43 base ranks, all three bioware feats, +50 skill bonus, and 60 int (+25 int modifier), that would give us...

X =((43+65+25)-25)+25)... X=133

However, the script won't return that.  Instead, the script will return:

X=((43+65+19)-25)+25... X=127.

The function (B+M+A) is capped at 127.  Any combination of gear, feat and int modifier numbers which goes above 127 will cap at that 127 mark.

Any script function which then starts adding to or subtracting from the number returned by (b+m+a) will not return correct results when (b+m+a) is greater than 127

The problem is further compounded by there not being a single function to get M's result.

That is where my on-equip/unequip suggestion comes in.  It obtains "M" by ferreting out all the 'spellcraft+X and "allskills+X" numbers on gear through the on-equip even.  It saves them to a variable that can then be called by our forumla above.

The bonuses from feats/spell effects does not need to be done with the on-equip routine.  Those can be added to the final result at the same time that "mystical insight" is applied as well.


We'll call the "equip" routine's number M1, and the rest of the modifiers (feats, spell effects) M2.

Now....

x= ((B+M1+M2)+A1

x= correct numbers, regardless of the 127 cap.

b = (base ranks) a =(ability modifier)
x =b+a+m (total score)
so we can get the value of a and b and x
therefore x-b-a = m (which is the item/feat/bonuses)

so the problem comes from the fact that x is never calculated correctly because it caps at 127 ?
Am I following the math of this problem correctly ?

Ok, thank you for taking the time on that, Manny.

I think I am getting it better now. If I am right, Manny's issue is actually nothing to do with what one class gets vs. another (its just anecdotal that Wizards see the issue sooner in their INT mod progression).

The issue Manny sees is that there is no way to make the math accurate without specifically calculating an accurate value from 1 to 50 for the enhancement bonuses/effect.

Even with Vagabond's workaround, while the playing field is leveled off, there *is* an artificial "bloat" that occurs to the final spellcraft value.

So it seems that its not about the 'gap' between classes, as that can be resolved... its that even if you close that 'gap', the numbers are not accurate, they are just 'fair'.

I do see an advantage to Manny's proposed equip scripting, too.... since it could calculate all those sources of enhancement individually, it would be able to accurately store a value greater than 50.... so the enhancement bonuses would not be "capped" anymore, which would prevent them from being devalued for PCs who really invest a lot into getting them.

If you read this, Manny, please let me know if I am starting to get it?

On a related note - it appears has made a new change to epic castings per day....

Crid started with his usual 8 but over the course of 30 minutes IRL did not recover any castings at all. I rested and got them back, but still no recovery.

Suspecting a server glitch, I reset the server (since no one was on) and now at logon, when Crid crosses the trigger in the Astral Conjunction his casts reset to 8 and then seem to count down to 0 in a couple seconds.. leaving him with zero epic casting ability.

Can't say I am thrilled at the moment *_*

You got it exactly


As for the epic castings.... I noticed that too.... except in the opposite direction.  Auger (my palemaster) has more casts than he should.  His casts were still regenerating.

Well, I suppose I shouldn't complain.. I have been one of the lucky few since the inception of AEMS that always got the right number of casts and never had an issue with recovery or seeds not working for me that worked for others.

I guess its my turn to see the other side of it.

With the astral conjunction refresh trigger, it's always been that it doesn't refresh epic casts. It'll refresh everything but the epic castings, and I've gotten that 'zap on down to 0' thing before (used all casts, popped thruogh the OOC spell test area to get into conjunction to grab the latest reward chest the character had earned.... as I crossed the trigger her casts went up to 8, but then the next moment counted down to 0 again).

When I log in, I'll test out with my other epic casters, see what behaviors/cast numbers they get as well.

Rested to get my castings back, got all 8. Went to spellcasting test area and used exit to return to astral conjunction. Hit trigger in conjunction. It not only doesn't refresh castings, but it removed all 8 of the casting that Crid already had.

Before I had reset the server, he was able to log in and keep all 8 of his castings when he crossed the trigger.

Logged in Gabriel - he got his full number of casts. Hit the trigger multiple times to make sure, and it calculated correctly each time.

Went out and had to use his cloud cover seed a few times... almost 20 IRL minutes, zero recovery.... ran out of castings, then logged off.

Checked 3 of mine.  Two are still getting correct number of casts (cleric and sorc).  Aga (40 wiz) is still only getting 4.  Nobody's regenerating casts over time.

Server is laggy as hell at the moment though, not sure if that has anything to do with it.... seriously laggy.  Took 3 minutes just now for my journal to actually display the list of portal codes, took nearly a full minute for an echest to appear after summoning it, boomerranging like crazy when trying to walk.

Think 's updating the module for tonight's gamenight?  Only thing I can think of

Manny --

Thanks for the full explanation. I did note earlier that all would eventually get some points lost in the cap, I was just trying to simplify the matter so that all casters lost out equally, with the least amount of server resources to do so. Typically wizards lose first, my thought was to level that field.

When I coded for a NWN PW, my goal was to always do things with the least amount of scripting/resources, as lag is always something to be avoided. When trying to solve for a scripting issue, I always keep that foremost in my mind, for better or for worse.

With regards to the lost points -- all that's really being lost is some of the +50 spellcraft gear that is necessary to get to the cap. Without any gear, we have 43+3+10+2 = 58, +10 if you count ascension, so 68. 127-68 = 59. Even with a casting stat (or int) of 50, that's +20, yielding 39 bonus "allowed". Yes, we can get gear to +50, and some of that gear would be wasted (+11), but that's no different in my mind than the +12 stat cap for normal bonuses, or the +20 cap for AB. Even in the previously used example (the uber-max wizard), the "loss" of spellcraft was only +13 points (140 max vs. 127 cap) In my mind, a heavily invested caster can choose to use other gear if they've capped out spellcraft. My epic druid chooses not to have any +X stat gear because he caps out using epic magic. To me, this is a similar problem. In truth, with the current enchantment system, I don't see getting +50 to be any kind of a serious challenge, as pretty much any epic caster can self-enchant items to +10, so "disallowing" some of that due to an engine cap doesn't seem to be that much of a penalty, but that's just my opinion, and I can certainly fully understand Manny's position on this matter, and appreciate it.

I agree that there are lost points, but I guess I just accept that and would rather have the benefit of the stat investment be an additional add -- so it's not completely wasted -- then adjust the DCs accordingly. Ascension and Reincarnation bonuses can be scripted in, so they are not subject to the cap (or, in this case, potentially added twice, but I'd overlook that, too, as the investment makes that a worthwhile bonus to me).

If I had to script something to add everything in, I suppose I'd keep a variable on the PC with a running total calculated from OnEquip/Unequip, but that's still a laggy proposition, as it would need to cycle through every element of every piece of gear, every time. Could be done (i.e. PC needs to rest before epic casting after reset/login, run each piece of gear and put a variable on the gear with the bonus, then just use that variable OnEquip/UnEquip to update the variable on the PC). Doing it that way would minimize server lag and still accomplish what you're asking for. Plus, by keeping the Epic Casting counter at 0 prior to that first post-reset rest, you can potentially avoid all the wonkiness that's being reported above. The casting counter can be properly calculated and reset at the time of rest, etc. As it now stands, it seems like the counter is somehow kept on the PC and never reset--as evidenced by my multiclass wiz using the scales and releveling as a pure level 40 wizard, but still only seeing 4 casts of epic magic.

The evenness is what really caught my attention at first, mostly in that non-wizards wouldn't lose points, at least not until they got super high int (which is a rare setup).  Were it to cap everybody, then I would have totally agreed that just living with the limit

The one aspect about the on-equip event idea that I see as problematic myself is even if searching for just +1 to +10 on each item, a special provision for the flow-watcher's +15, and just the +1 through +3 "all skills" properties will itself be intensive script wise.  Ten slots, each looking for 14 separate possible properties.  Well, actually 11 slots, not sure if there are any VFX helmet type items that have +X all skills/spellcraft on them.... those apply as a hide item.

I'm not sure how much load even just an on-equip/on-unequip event check would be, how much fuss it woudl be if the item was loaded up with other properties as well.  I just can't think of any other method to suggest to get all the accurate numbers which would be any more streamlined.

For the rest before.... the refresh trigger in the conjunction could handle that as well?

And yeah.... under the current system, the counter is flubbed, I got the same issue with my wizard who I switched from multiclassed wiz30/animator7/farstepper3 to wizard 40.... only gets 4 casts (previously he was getting 7).

That idea about checking the item at-rest and putting as a single easy to grab variable on the item's a good one.  The only slipup I could see would be when you rest, you unequip the shield and weapon hand, which would need a special check to grab those numbers before unequipping for rest...

And a PC could very well switch held gear between rests.  Mage rests while having flow-watcher equipped.  But then while playing, swaps for a maximizer staff, or some other weapon, ect...

Maybe a check on-acquire (would fire off first time one logs in after reset, plus whenever one picks up an item).... use that to get the skill bonuses, place as a variable on the item....

But then would need to check through gear for that variable every time the PC casts.  That's one reason I thought the on-equip would be the most efficient way to get those numbers.

I'll see what I can do about getting the various parts of the Spellcraft calculation separated for the rescripting I'm doing.

I'm also working on a fix for the castings per day issue.

Any changes to the system will go live after the next hak update (since the new system relies on changes I've made to several 2da files and at least one visual effect model).

My wizard's epic magic spells no longer refresh with reset.  After reset, have to rest to get them back.

And since this started happening, I never ever get 8 casts, only 7.