Custom FP power tree stacking issue.

[darthrevanrlz]

Heya.

 

Mmm. Had a few hours so I figured I could go back to scripting and focus on buffs for a change.

 

Effects, duration, in-game appearance in the selection tree, .2da... all that works just fine.

 

My problem lies with stacking. Just for the info, it's just a 2-tiers buff.

 

I know the *plain* line for "no effect if an upgrade is already in effect" and "remove lower version" are:

 

Sp_RemoveRelatedPowers( oTarget, GetSpellId())

if( !Sp_BetterRelatedPowerExists( oTarget, GetSpellId() )

 

Just used oTarget as a random variable refering to the party or player.

In k_inc_force, we'd find "FORCE_POWER_WHATEVER" instead of GetSpellId().

 

Tried to literally ADD a new spells to k_inc_force and the according entries at the end of the script (nRelated), but the script just won't aknowledge it. Guess the "case FORCE_POWER_WHATEVER" is hardcoded...

 

I mean, all I did was copy/paste an already existing spell and modding the data just for the sake of testing (AKA I copied/pasted valor and changed all "FORCE_POWER" entries to "FORCE_POWER_BUFF" - It doesn't get any simpler). Didn't work out at all since the first "case FORCE_POWER_BUFF" never was aknowledged.

 

I suppose (not even sure on that one) a way to go around this would be to put the effects of each "tier" into a single script and add "int FORCE_POWER_WHATEVER = 999" at the top of the script and later on a:

 

int nSpell = GetSpellId();

 

That's what was done with the zombie/floatingsabers mod. Sadly enough, it's pretty much the only ones dealing with FP TREES.

 

Viable solution, I guess, but I'd rather make the script compatible with other FP mods.

 

So, what, do I have to punch in at the end of the script the "nRelated" FPs like it's done in k_inc_force? Does the "case FORCE_POWER_WHATEVER" format is the solution outside of k_inc_force???

 

And how would I go about making it work?

 

Well?

 

DRRLZ

 

P.S. Oh, and if Stoffe happens to be my savior on this one... PLEASE, don't use the variables from your st_force_inc, lol. Doesn't exactly help with dealing with that pesky k_force_inc since I don't even know what's in your script...

[Darkkender]

The simplest first question first. Did you start a new game for testing or an existing game? There are numerous possible glitches that could be popping up for this particular type of modding. I realize there are those here who miracuolosly never have failure's when it relates to existing games however there are equally as many here who have no luck whatsoever.

[darthrevanrlz]

The simplest first question first. Did you start a new game for testing or an existing game? There are numerous possible glitches that could be popping up for this particular type of modding. I realize there are those here who miracuolosly never have failure's when it relates to existing games however there are equally as many here who have no luck whatsoever.

 

Was testing offensive spells last week and they worked just fine. I highly doubt the type of save game has anything to do with the custom spells I'm working on.

 

The point is that I got it WRONG when trying to not have same tree buffs stack. Mostly because I'm not sure how it should be done OUTSIDE of k_inc_force and because no public mods did it aside the few I mentioned (floatingLsbr/zombie - and I did mention how I was looking for another method)

 

I'm asking how the feature should be scripted.

[stoffe]

if( !Sp_BetterRelatedPowerExists( oTarget, GetSpellId() )

 

This function won't be useful for your own custom powers. It specifically checks for the standard powers and does not work generically for anything else, since scripts can't do direct 2da file lookups. You'll have to write your own checks for your new powers. You can use the GetHasSpellEffect() function to check if a creature is affected by a particular spell (first parameter is the line number in spells.2da).

 

 

In k_inc_force, we'd find "FORCE_POWER_WHATEVER" instead of GetSpellId().

 

Those are just constants (listed in nwscript.nss) that represent line number values in spells.2da, to make it a bit easier for a human script reader to remember what the value refers to. You can just use the numbers directly instead and avoid some needless global variable declarations (unless you use a script compiler capable of handling constant declarations). If you just need the line number for the currently cast spell, use the GetSpellId() function.

 

I suppose (not even sure on that one) a way to go around this would be to put the effects of each "tier" into a single script

 

It should work either way with a separate impact script for each tier, or a combined one for all of them. That's just a matter of taste how you prefer to organize things. In either case you'd need to know the line numbers in spells.2da for your custom spells since you'd need to check for other powers of the same "school" already being active.

 

Viable solution, I guess, but I'd rather make the script compatible with other FP mods.

 

You can use mod installers to do this. I know TSLPatcher can be used to that effect, not sure if KISS can do it. In the former you'd stick the line numbers at install-time into tokens which the installer would insert into the scripts and recompile them before placing them in the user's override folder. That way you wouldn't have to hardcode the line numbers into your script, but they'd match whatever line numbers they end up at. The same thing could be used to properly reference dynamically added effect icons (in effecticon.2da) from your impact scripts to make sure your powers are properly displayed in-game in the Effects screen.

 

 

So, what, do I have to punch in at the end of the script the "nRelated" FPs like it's done in k_inc_force? Does the "case FORCE_POWER_WHATEVER" format is the solution outside of k_inc_force???

 

Are you referring to the Sp_BetterRelatedPowerExists() function? If so I wouldn't suggest modifying the standard include file needlessly. Make those checks directly in your scripts instead (or use a custom function in an include file of your own).

 

P.S. Oh, and if Stoffe happens to be my savior on this one... PLEASE, don't use the variables from your st_force_inc, lol. Doesn't exactly help with dealing with that pesky k_force_inc since I don't even know what's in your script...

 

This one? st_inc_force.nss.

 

(It has no global variables declared.)

[darthrevanrlz]

This function won't be useful for your own custom powers. It specifically checks for the standard powers and does not work generically for anything else, since scripts can't do direct 2da file lookups. You'll have to write your own checks for your new powers. You can use the GetHasSpellEffect() function to check if a creature is affected by a particular spell (first parameter is the line number in spells.2da).

 

Ah. No wonder it wouldn't work.

 

Got it working just fine this time.

 

That being said... I only used TSLPatcher for .2da and .tlk so far... It WILL be able to handle two *different* dummy values referring to the same .2da in a same script, right?

 

EDIT: Would've posted the script or at least a sample if any other noob wanted the ref, but the forum just keeps CRASHING whenever I try... The hell?

[stoffe]

That being said... I only used TSLPatcher for .2da and .tlk so far... It WILL be able to handle two *different* dummy values referring to the same .2da in a same script, right?

 

Unless I've missed something all 2DAMEMORY# and StrRef# tokens will be substituted whenever found a script, just like they would if you assigned them to a 2DA column or GFF field.

 

If you for example assign the RowIndexes of two newly added lines in spells.2da to 2DAMEMORY1 and 2DAMEMORY2 respectively, any occurences of #2DAMEMORY1# and #2DAMEMORY2# in a script (set to be processed for tokens and recompiled) would be substituted for those line numbers.

 

Just make sure, if you are using include files with tokens, that you add those first to the CompileList in the patcher config file, since the files are processed in the order they are listed. Then add the files that are using those includes files to the list to allow them to be properly recompiled.

 

Also make sure that the nwnnsscomp.exe that came with the patcher, and a corrected copy of nwscript.nss, are present within the tslpatchdata folder.