Lone Wolf Development Forums

Lone Wolf Development Forums (http://forums.wolflair.com/index.php)
-   HL - D&D 5th Edition SRD (http://forums.wolflair.com/forumdisplay.php?f=89)
-   -   Configurable Alternating Choice (http://forums.wolflair.com/showthread.php?t=61649)

xWhiteGodx November 26th, 2018 11:55 AM

Configurable Alternating Choice
 
The current quandary I stumbled upon is making a hierarchy stack to determine whether or not to increase the value of a Configurable. Currently I have this eval script (Post-Level, 10,000):

Code:

      doneif (tagis[Helper.Disable] <> 0)

if (#hasability[cHydroKinet] + #hasability[cGeokinet] + #hasability[cAirKinet] >= 0) then
      hero.childfound[cfgWildTalent].field[cfgMax1].value += 1

elseif (#hasability[cPyrokinet] + #hasability[cEE1PyroKinet] >= 0) then
      hero.childfound[cfgWildTalent].field[cfgMax1].value -= 0
endif

The script is in the Special Ability [cEE1PyroKinet]. What I want to do, is make it so
Quote:

If Class has [cHydroKinet], or [cGeokinet] or [cAirKinet](Primary Ability Table for class)
then
Quote:

increase [cfgWildTalent].field[cfgMax1].value by 1
However,
Quote:

If Class has [cPyrokinet]
then
Quote:

Decrease [cfgWildTalent].field[cfgMax1].value by 1
The issue I run into, is that it either works all the time, or works none of the time - meaning it'll always give a +1 to the Configurable, regardless of if I have those abilities or not, or it doesn't give it at all. I'm stumped on this one and have spent 2 hours working on it. I can't progress through the class without making this one piece of script work, because it needs to be copy/pasted (then slightly modified) for other abilities of the same.

:confused::confused::confused:

xWhiteGodx September 23rd, 2019 05:52 PM

Necroing the hell out of this thread as it's still unresolved, even almost a year later.

The issue still persists - I can't figure out why the script won't deactivate or activate that bonus for other requirements being met.

Script 2: Final Phase; 10,000

Code:

      doneif (tagis[Helper.Disable] < 0)

if (#hasability[cHydroKinet] + #hasability[cGeokinet] + #hasability[cAirKinet] > 0) then
      hero.childfound[cfgWildTalent].field[cfgMax1].value += 1

if (#hasability[cPyrokinet] > 0) then
      hero.childfound[cfgWildTalent].field[cfgMax1].value -= 1
endif
endif

No matter what I do for the script, if the Hero has cHydroKinet, or cGeokinet, or cAirKinet and cEE1PyroKinet, it doesn't increase [cfgMax1] by 1 point.

>Assume Hero chooses Water for base element [cHydroKinet]
>Hero reaches level 7, Hero chooses expanded element to dive into, or expands current element
>If Hero chooses Fire as expanded element [cEE1PyroKinet], Hero should get [cfgMax1] +1

This does not happen. Why? I get no errors when saving and testing, but it doesn't actually do anything. Even if I put an elseif, nothing changes. I could always give an automatic [cfgMax1] +1 for reaching level 7, when the element can be chosen, but there's no way to reduce that by 1 if they pick a certain thing. I would really love help with this.

The intent is that if the Hero has any element besides fire as the starting element to increase [cfgMax1] by 1, and not to if fire is the starting element.

dungeonguru September 24th, 2019 03:43 AM

Sometimes it's not just the scripting, but the timing. I see you've been in post-level and final phases, have you tried earlier? Have you tried moving the phase internal timing from 10000 to 15000 or earlier to 5000?

I assume you have, so here's a rewrite that doesn't require you to use a subtraction and nested if/then looping.

Code:

doneif (tagis[Helper.Disable] < 0)
~ drop here if we have cPyrokinet already
doneif (#hasability[cPyrokinet] > 0)
~ add 1 to my cfgMax1 otherwise.
hero.childfound[cfgWildTalent].field[cfgMax1].value += 1

In this method we test to see if we have cPyrokinet, and only add 1 if we do.

dungeonguru September 24th, 2019 03:48 AM

Also, the

doneif (tagis(Helper.Disable] < 0)

seems off, i've only seen it in code as

doneif (tagis[Helper.Disable] = 1)

or

doneif (tagis[Helper.Disable] <> 0)

I'm not sure if the Helper.Disable count ever gets a negative number but wondering if it might not be initialized correctly during certain phases and that's kicking you out of the script altogether early.

xWhiteGodx September 25th, 2019 04:39 PM

Yea, I realized that it was set to a negative value, but it really didn't change/do much. Even using your script and making some small changes didn't do anything besides ignore the doneif (#hasability[cPyrokinet] > 0) section and automatically add to cfgMax1.

It seems that the eval script outright ignores the entire if unless it's >= 0

This is what I have for the script right now:

Code:

doneif (tagis[Helper.Disable] <> 0)
~ drop here if we have cPyrokinet already
if (#hasability[cPyrokinet] > 0) then
~ add 1 to my cfgMax1 otherwise.
hero.childfound[cfgWildTalent].field[cfgMax1].value += 1
endif

However it does nothing, but gives no errors. If I change the > 0 to >= 0 then it always works (as it's always equal to or greater than zero). Changing it to = 1 or anything of that variation doesn't work (well, > 1 works because it's the same as >= 0).

I honestly think the macro itself refuses to work in that scenario. In a 2nd script where I increase cfgMax2, 3, and 4 as part of grabbing the ability the scripts are on [cEE1PyroKinet]. Those work perfectly, and if I add

Code:

~Increase Basic Blasts by 1
    if (field[xTotalLev].value >= 7) then
      hero.childfound[cfgWildTalent].field[cfgMax1].value += 1


endif

to the end of the second, or even the first eval script, it'll always give a +1 to it, but reversing the other script to
Code:

doneif (tagis[Helper.Disable] <> 0)
~ drop here if we have cPyrokinet already
if (#hasability[cPyrokinet] > 0) then
~ add 1 to my cfgMax1 otherwise.
hero.childfound[cfgWildTalent].field[cfgMax1].value -= 1
endif

produces the same problem. I think the (#hasability[cXXX] >0) line just simply does nothing in regards to determining when to add or subtract a value for cfgMax1. :confused::confused:

It's been driving me crazy.

dungeonguru September 26th, 2019 03:30 AM

I did a search and I think the issue is with the abillity getting added in a configurable too late for #hasability[] to get a proper tag count and is always returning a 0 or being added via configurable isn't setting the right tag for #hasability to include it in a count.

ShadowChemosh talks about this in a thread here and suggests using hero.childlives[xxx] as the test criteria and also says #hasfeat[] has the same issue.

I'm not sure if this will fix your issue, but it's worth trying.

xWhiteGodx September 26th, 2019 01:17 PM

Quote:

Originally Posted by dungeonguru (Post 282569)
I did a search and I think the issue is with the abillity getting added in a configurable too late for #hasability[] to get a proper tag count and is always returning a 0 or being added via configurable isn't setting the right tag for #hasability to include it in a count.

ShadowChemosh talks about this in a thread here and suggests using hero.childlives[xxx] as the test criteria and also says #hasfeat[] has the same issue.

I'm not sure if this will fix your issue, but it's worth trying.

Oh you madman. Thank you for finding this niche bit of info. I don't know how I didn't find it after off and on looking for a year. I can finally (hopefully) finish this abomination of a class. I'm not even finished with it, but I'm looking at:

1 class
1 class level
16 class specials
131 custom abilities
25 spells

The latter 2 will be increasing now that the piece of code correctly identifies it. Woop!


All times are GMT -8. The time now is 04:50 AM.

Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.