Community Editor Projects - Mythic Psionics

[Quintain]

All,

Going through the abilities that use mythic power to enable and a thought occurred to me. Is there a way to tie the use of a mythic ability to the Mythic Power tracker in the tracked resources and abilities on the In-Play tab so that when a mythic ability is activated, the tracker value is reduced by the number of points spent, or should that housekeeping be done by the user?

 

[Quintain]

Ok, working on Potent Pool again. Trying to work out how to limit the number of times that the ability can be chosen. Can't use Max Limit due to it's variable nature -- the maximum number of times it can be chosen is less than or equal to the max power level for the chosen psionic class:

Custom expression: Select from classes where CasterSrc.Psionic

hero.childfound[cPUMPoPool].field[usrChosen1].chosen.field[cPsiLevMax].value

Unfortunately, despite my best efforts, this always resolves as zero, which disables the ability (it's in a pre-req script -- I pulled the example from the eidolon natural armor ability).

       var allowed as number
       allowed = hero.childfound[cPUMPoPool].field[usrChosen1].chosen.field[cPsiLevMax].value
       ~ if we're a pick, then there must be cPsiLevMax
       ~ or fewer copies of this ability
       if (@ispick <> 0) then
          validif (tagcount[HasAbility.cPUMPoPool] <= allowed)

        ~ otherwise, look for fewer, since we're adding this
       else
         validif (tagcount[HasAbility.cPUMPoPool] < allowed)
       endif

        @message = "You may not have more than " & allowed & " copies of this ability."

Edit: Ok, found a partial solution (in that it makes the ability active)

    var allowed as number
    allowed = [B]maximum(1,hero.child[cPUMPoPool].field[usrChosen1].chosen.field[cPsiLevMax].value)[/B]
     ~ if we're a pick, then there must be cPsiLevMax
     ~ or fewer copies of this ability
       if (@ispick <> 0) then
          validif (tagcount[Ability.cPUMPoPool] <= allowed)

        ~ otherwise, look for fewer, since we're adding this
       else
         validif (tagcount[Ability.cPUMPoPool] < allowed)
       endif

        @message = "You may not have more than " & allowed & " copies of this ability."

However, when choosing this ability for the fist time, it throws an error:

Attempt to access non-existent child pick 'cPUMPoPool' from script
- - -
Attempt to access non-existent child pick 'cPUMPoPool' from script
- - -
Attempt to access non-existent child pick 'cPUMPoPool' from script
- - -
Attempt to access non-existent child pick 'cPUMPoPool' from script

I know why it's throwing the error, but can't see a way around it. The pre-req requires information from the character about the maximum psionic power level for any psionic classes. This information exists, but any method of referencing it throws an error (so far). I've attempted a straight pick reference as well as a foreach loop. Any assistance would be appreciated.

Edit: looks like the solution was related to timing. Changed the timing on the script to Post-Attributes 21000 and it can be added without an error now.

 

[ShadowChemosh]

Edit: looks like the solution was related to timing. Changed the timing on the script to Post-Attributes 21000 and it can be added without an error now.

Its not a timing issue. I assume you have this script running on a Pre-Req script. In such a case you need to know if you are a Thing or Pick and access yourself using altpick or altthing as the transition.

Otherwise you are trying to access a Pick that does not yet exist on the hero.

Last thing is how do you know 'which' Pick you are accessing? So you add this ability three times to a character. You now have three Picks on the hero with the same unique id. Each one will also have a dropdown to select a class and each Pick could have selected a different class.

1) How do you plan to enforce that "one" class is selected even though this ability is added multiple times?

2) How do you plan to get around the issue of NO selected class when your ability is only a Thing?

I would recommend working on the first issue only for now.

 

[ShadowChemosh]

All,

Going through the abilities that use mythic power to enable and a thought occurred to me. Is there a way to tie the use of a mythic ability to the Mythic Power tracker in the tracked resources and abilities on the In-Play tab so that when a mythic ability is activated, the tracker value is reduced by the number of points spent, or should that housekeeping be done by the user?

Based on how HL scripts work. How would you accomplish this?

You want the activation to reduce the mythic power tracker total when an ability is activated. But an ability does not have to stay active for more than a round. Meaning as soon as you turn "OFF" the tracker the mythic power total will go right back up.

 

[Quintain]

Its not a timing issue. I assume you have this script running on a Pre-Req script. In such a case you need to know if you are a Thing or Pick and access yourself using altpick or altthing as the transition.

Otherwise you are trying to access a Pick that does not yet exist on the hero.

I've never seen "altpick" or "altthing", nor know how they work. With the new timing, the error that previously occurred no longer occurs. The pre-req is intended to determine how many times the thing can be added (and the error happened when the timing was set prior to what it is now. It isn't intended to validate the pick.

Last thing is how do you know 'which' Pick you are accessing? So you add this ability three times to a character. You now have three Picks on the hero with the same unique id. Each one will also have a dropdown to select a class and each Pick could have selected a different class.

1) How do you plan to enforce that "one" class is selected even though this ability is added multiple times?

2) How do you plan to get around the issue of NO selected class when your ability is only a Thing?

I would recommend working on the first issue only for now.

1) There is no need to enforce anything in regards to the pick. If the user has multiple psionic classes that have different maximum psionic power level values, it behooves them to pick the one that gives them the maximum benefit. The 1st pick determines the value the application uses on future picks.

2) If there is no pick, the ability doesn't add power points. Since the character's power point pool is a cumulative value of all psionic classes, all the user needs to do is make a pick, no matter what it is (since it is a list of all psionic "caster" classes on the hero) to add power points to the pool.

I've pushed a commit if you want to look at the full code set.

 

[Quintain]

Saving this for posterity:

    <prereq message="You can take this ability once for each level of powers you can manifest of the chosen class.">
      <validate><![CDATA[
    var allowed as number

   ~ if we're a pick, then there must be cPsiLevMax

   ~ or fewer copies of this ability

   if (@ispick <> 0) then

    allowed = altpick.field[usrChosen1].chosen.field[cPsiLevMax].value
     validif (tagcount[Ability.cPUMPoPool] <= allowed)

   ~ otherwise, look for fewer, since we're adding this

   else

     allowed = altthing.field[usrChosen1].chosen.field[cPsiLevMax].value

     validif (tagcount[Ability.cPUMPoPool] < allowed)

   endif



   @message = "You may not have more than " & allowed & " copies of this ability."]]></validate>
      </prereq>

 

[ShadowChemosh]

1) There is no need to enforce anything in regards to the pick. If the user has multiple psionic classes that have different maximum psionic power level values, it behooves them to pick the one that gives them the maximum benefit. The 1st pick determines the value the application uses on future picks.

And you find the "First" pick how? The gamer knows what the First pick is how?

You understand that hero.child[] gets you a "random" Pick. NOT the first one you see in the list. The UI and hero.child[] are NOT linked together in anyway.

Unlike Class Specials no Helper.First tag exist to separate them.

So if the user selects classes Psion, Wilder & Psycic Warrior your script will get one of these randomly to test the power level. I don't see that as being a good thing.

 

[Quintain]

And you find the "First" pick how? The gamer knows what the First pick is how?

You understand that hero.child[] gets you a "random" Pick. NOT the first one you see in the list. The UI and hero.child[] are NOT linked together in anyway.

Unlike Class Specials no Helper.First tag exist to separate them.

So if the user selects classes Psion, Wilder & Psycic Warrior your script will get one of these randomly to test the power level. I don't see that as being a good thing.

The first pick is through the Potent Pool Thing and is restricted to CasterSrc.Psionic classes.

If it is indeed random, I'm open to suggestions on how to fix. Unfortunately, I'm at a dead stop coding-wise. If I have altpick/altthing in the pre-req script, compile and then try to add the Potent Pool thing to the character, Hero Lab now crashes. I have a ticket open with LW.

Tests:

A level 5 psychic warrior (max power level 2), level 5 psion (max power level 3) and a level 10 tactician (max power level 5). I then added 3 Potent Pool things to the portfolio (Mythic Level 3). Initial pick was tactician. I never violated the rule as I coded it. If I changed the choice of things 2 and 3, I never violated the validation rule -- even if I picked psychic warrior, which can only have 2 potent pool things added. Only when I changed the 1st potent pool thing choice to psychic warrior did I violate the rule for all three things. I changed the 1st potent pool choice back to Psion and the validation exception went went away. After about 50 or so changes, I never saw where the validation rule chose anything other than basing itself off the choice of first potent pool thing.

Now, I agree that this initial method isn't the greatest. What I would like is a single thing added with a chooser, and some sort of notation on how many times it has been chosen. But how to accomplish that is a bit outside of my realm at the moment.

 

[Quintain]

Based on how HL scripts work. How would you accomplish this?

You want the activation to reduce the mythic power tracker total when an ability is activated. But an ability does not have to stay active for more than a round. Meaning as soon as you turn "OFF" the tracker the mythic power total will go right back up.

I wasn't referring to the "activation" of an ability like when you select a checkbox, but more the use of tracked resource ability counting against not only the ability itself, but when incremented, the mythic power counter increments as well.

 

[ShadowChemosh]

I wasn't referring to the "activation" of an ability like when you select a checkbox, but more the use of tracked resource ability counting against not only the ability itself, but when incremented, the mythic power counter increments as well.

That would actually work. Not sure its really helpful as it will add even more trackers to the In-Play tab. That tab already gets so much stuff and then add mythic and its even worse.

My vote would be not to do this and let the gamer just use the "one" mythic power tracker to count the points spent.

 

[ShadowChemosh]

The first pick is through the Potent Pool Thing and is restricted to CasterSrc.Psionic classes.

If it is indeed random, I'm open to suggestions on how to fix. Unfortunately, I'm at a dead stop coding-wise. If I have altpick/altthing in the pre-req script, compile and then try to add the Potent Pool thing to the character, Hero Lab now crashes. I have a ticket open with LW.

Tests:

A level 5 psychic warrior (max power level 2), level 5 psion (max power level 3) and a level 10 tactician (max power level 5). I then added 3 Potent Pool things to the portfolio (Mythic Level 3). Initial pick was tactician. I never violated the rule as I coded it. If I changed the choice of things 2 and 3, I never violated the validation rule -- even if I picked psychic warrior, which can only have 2 potent pool things added. Only when I changed the 1st potent pool thing choice to psychic warrior did I violate the rule for all three things. I changed the 1st potent pool choice back to Psion and the validation exception went went away. After about 50 or so changes, I never saw where the validation rule chose anything other than basing itself off the choice of first potent pool thing.

Now, I agree that this initial method isn't the greatest. What I would like is a single thing added with a chooser, and some sort of notation on how many times it has been chosen. But how to accomplish that is a bit outside of my realm at the moment.

My only idea is to similar what we did before using a Unique bootstrapped helper ability. This "helper" Mythic Ability will be the one that chooses the class. Sense it will be "Unique Add" even if we add several Potent Pool abilities we only have one chooser.

1) Create new Potent Pool Mythic ability (Helper) thing. This has the class chooser. Then set it to Unique and give it a tag of "Helper.Helper".
1a) You can even add the points on the helper thing also. You can do an hero.tagcount[Ability.cPUMPoPool] to know how much to increase the points by.
2) Bootstrap the Helper Potent Pool to the Potent Pool mythic ability.
3) Redo your logic on cPUMPoPool to get the "class" from the Helper Potent Pool.

This way gets you a "single" class selector for a gamer to select one time. Your script is easier because you don't have to deal with multiple Potent Pools.

That is how I would handle this. I am pretty much busy this whole weekend. Give it a try and I can help next week if you have issues...

 

[Quintain]

I had thought of something similar before moving to what I have now. One thing the basic ability did not have that the class special had was having selection fields to create the drop down list. It was kind of a sticking point.

 

[ShadowChemosh]

I had thought of something similar before moving to what I have now. One thing the basic ability did not have that the class special had was having selection fields to create the drop down list. It was kind of a sticking point.

The basic ability does have a dropdown but you have code it in XML not the editor. Not sure why they did that way but it will work.

In this case I would not make it a basic ability I would make it a standard Mythic Ability but the "Helper.Helper" tag will prevent it from being individually selected.

 

[Quintain]

Ok, so you have a helper class special with a dropdown bootstrapped to another class special?

 

[ShadowChemosh]

Ok, so you have a helper class special with a dropdown bootstrapped to another class special?

To be sure we are on same page.

Potent Pool is a Custom Class Special located in the editor as a "Class->Custom Ability". I am saying make a new "Custom Ability" called Potent Pool with an id of xPUPoPool2 and set 'Uniqueness' to Unique. Then on the "tags" button add Helper.Helper and do not set it available to any class. Bootstrap xPUPoPool2 to cPUMPoPool.

This new Custom Ability xPUPoPool2 will have the class selector and the logic for calculating the point progression.

P.S. - Sorry don't have time to work out the progression math for the point total. But you can use hero.tagcount[Ability.cPUMPoPool] to know how many times Potent Pool has been added to the hero...

 

[Quintain]

To be sure we are on same page.

Potent Pool is a Custom Class Special located in the editor as a "Class->Custom Ability". I am saying make a new "Custom Ability" called Potent Pool with an id of xPUPoPool2 and set 'Uniqueness' to Unique. Then on the "tags" button add Helper.Helper and do not set it available to any class. Bootstrap xPUPoPool2 to cPUMPoPool.

This new Custom Ability xPUPoPool2 will have the class selector and the logic for calculating the point progression.

P.S. - Sorry don't have time to work out the progression math for the point total. But you can use hero.tagcount[Ability.cPUMPoPool] to know how many times Potent Pool has been added to the hero...

I follow you. It's just odd that you have a custom ability that is bootstrapped to another custom ability. Mentally, I had them in a heirarchy, I guess.

 

[Quintain]

Update:

I made the changes per your idea. It worked out nicely. There is only one item that allows for a chooser -- in green, below the 1st item, additional items all reference the original, and switching between classes with different maximum power level values validates or invalidates the choices.

It seems, however that the validation logic is invalidating all picks, not just the one that causes the validation failure. It still works, mind you, but is there anyway to tweak this so only the violator(s) are flagged red?

 

[Quintain]

Status Update: I've implemented all the abilities that I believe can be implemented. We should be good to release at this point.