• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Looking for feedback on strategy for custom user file

Seeker1728

Well-known member
I’m working on a user file to create a SW version of Scion 2E. If you’re unfamiliar with Scion, it’s basically modern myth themed “supers” where a character is (usually) the child or chosen of a diety from one of earth’s mythologies. Initially I was going to just slap the Superpowers Companion onto the base SW but there were too many things missing with that approach, requiring I dig into the editor.

I’m trying to figure out a strategy in constructing the user file to handle all the components that a Hero typically has as assets. The following are the components from Scion used to construct a character with a brief description of what each represents and I was hoping I could get some feedback on my strategy for laying out the data collections and relationships.

Calling
There are 11 of these arch-types that serve to present a role, for example Guardian, Trickster, etc. Each grants access to a restricted list of appropriate powers. A Hero inherits one of his parents Callings, and then can choose 2 additional ones to represent his own nature.

Knacks
These supernatural talents stem from a Scion's Calling, basically letting them have cool/unique abilities that are thematically tied to what the Calling's purpose serves.

Knacks come in tiers, Mortal, Heroic, Demi-God and (starting at level 16+) God as a rough correlation to SW’s Advancement Ranks. Some of these Knacks fit neatly into the Edge category, but others are more appropriate for Powers. I.E. a Trickster could pick up the Edge Thief without having to meet the normal pre-reqs or he could pick Darksight, and as he progresses in rank he can acquire more choices from this list. Mortal tier Knacks seem served best by Edges and/or certain low-level powers/spells. Heroic Knacks are noticeably more potent and tend to be represented by Superpowers better than edges

Purviews
Thematic genuinely supernatural powers that mythological entities have. A Hero inherits one of his parents Purviews, then gets to choose 2 more to represent their natural affinity from a list that all gods/mythological entities draw from. As Scions advance in rank, they can either develop these further, or pick up new Purviews to be more versatile.

Mana
I know SW uses the term “power points” but this is IMO highly confusing since it uses the same term to refer to fuel for powers or the ability to choose powers. So, I’m going to use the term “mana” when I mean fuel, and not "Power Points".
Scion has a trait called Legend that serves several purposes, most of which can be summed up as SW’s Advancement system. However, it also acts as an energy reservoir that a Hero can use in one of two ways, he can “Imbue” or he can “Spend”.
• Imbue is when the hero commits a point to fuel a knack or power, but when he “turns it off” the point returns to him ready to be reused for something else.
• Spend is much like it sounds and represents a more significant effort on the part of the Hero. Spending this energy diminishes the Hero’s reserves until they do something specific to replenish it, merely resting doesn’t return the energy. They must do things like make sacrifices, offerings, pilgrimages, services, etc that ae thematically representative of their parent and/or pantheon.
As a result, I’m wanting to use Mana to represent in SW the same sort of energy allocation that exists in Scion.


So a Hero construction runs basically like this:

• Decide what Pantheon one wants to belong to.
• Decide which Diety from that pantheon is yo Daddy/Mama/Patron
• Decide on 3 Callings, 1 of which must be inherited from the Diety.
• Decide on what Knacks your Calling grants.
• Decide on what Purviews the Hero gets. He gets a pantheon specific Purview for free, plus 1 he inherits from his divine parent, and then can choose 2 more to represent his natural talents/inclinations.
• Allot points in Stats and Skills.


There are quite a bit more options a player can pursue, but the above is a typical/basic character building process. One can be a magical creation, critter, chosen champion, bound demon, etc. But I figured I’d want to start with the various pantheons, and once I get that running smoothly, I can add more options building upon that foundation later.

From looking at the tutorials and reading a bunch of threads as well as the HLwiki, I’m thinking I should make use of Race, Factions, Groups and of course, Edges/Powers from the SPC and perhaps the Fantasy Companion, for the building blocks.


I’m going to put this into the form of a example so that it’s easier to convey/follow my strategy on this. Lets say I want to create Mera, she’s the daughter of Loki who has her father’s talent for trickery, but also a natural born fighter with a keen sense of justice.


Asgardian gives her access to a pantheon specific power of using rune magic (something else I’ll have to figure out), a +1 on Toughness, and 1d4 in Fighting and Survival for free, and a list of Norse gods to choose from as her parent from within the Faction menu.

For her Callings she chooses Trickster (inheriting her father’s talent for cleverness), adding Judge and Warrior as her other two choices.

Knacks, she gets one Mortal level Knack from each Calling, plus 1 more of her choice.

Purviews, she chooses to inherit Loki’s talent for Deception, and then choose two more he has nothing to do with.

Then she chooses Hinderances, Edges, Stats, and skills and is ready to build her myth in the modern era.


So I’m thinking the way to construct the userfile is to:
1) Make Race stand in for Pantheon. This allows one to bootstrap innate benefits/hinderances and grants access to a restricted Faction.
2) Faction = The god one is the child of. This lets me restrict what the Callings and Purviews a Scion may claim.
3) Group = Callings, one can choose 3 initially, but at each tier of advancement, one can choose an additional Calling. The Callings Group has all Callings that a character choose from, but one must be the same as one’s parent. Choosing a Calling allows one to access a restricted list of Edges/Powers that represent Knacks.
4) Purviews = custom list of powers, so if one choose Deception as a Purview, fireball ain’t on the list of available choices.
5) Knacks = custom list of Edges and Powers that fit the theme of a calling, these will largely be custom but if there’s one that’s already present in the rules, I’ll save myself the effort and use it’s ID.

Does that seem like a good strategy going forward?
Are there any elements of the editor I should make a point to use or avoid like say, gizmos or domain?

Thank you for taking the time to read and share your input. :)
 
FWIW, Power Points (PPs) are used, as you noted, like "mana" might be in other systems, but the points used for Super Powers are differentiated as "Super Power Points" (SPPs), essentially the emphasis there being on "Super Power" points, if you will. So they share nomenclature but they are not both "Power Points", in that sense, so I think that's how most of us would distinguish the difference. Obviously whatever nomenclature you prefer for your game is what you should go with, though, I just thought I'd point that out is all.
 
FWIW, Power Points (PPs) are used, as you noted, like "mana" might be in other systems, but the points used for Super Powers are differentiated as "Super Power Points" (SPPs), essentially the emphasis there being on "Super Power" points, if you will. So they share nomenclature but they are not both "Power Points", in that sense, so I think that's how most of us would distinguish the difference. Obviously whatever nomenclature you prefer for your game is what you should go with, though, I just thought I'd point that out is all.

Thanks for the distinction Zarlor, it was just hella confusing reading that book after reading the Core rules, where they didn't use the S for SPPs, I kept flipping back and forth trying to find out how Supers fueled their powers a till I finally had to resort to searching Reddit on the matter.

Out of curiosity, would you happen to have a way off hand to be able to make that distinction evident in HL? Or is that just something that's way more bother than it's worth?
 
Yeah, the Super Powers Companion works differently. the Power Points are used to purchase the powers, and there is no cost to use them. So, no Endurance tracking or anything like that.

Note that the Super Powers Companion Arcane Background is not compatible with the multiple Arcane Backgrounds from SWADE. The Super Powers Companion has rules about that, and it operates in a totally different fashion.
 
True, in most setting you probably wouldn't use SPPs and PPs together, but if you are making a settings file where you wanted to use both... I want to say there is a way to change the name from "Power Points" to say "Mana"... maybe? I haven't touched a data file in YEARS at this point, and CC would definitely know the answer to that better than I would anyway.
 
Sorry to bother again, but even with the assistance of a buddy who's a software developer, we've been running into a number of walls that I need some help with. Though I found some posts that would address some of my issues, the unfortunate tendency was this was chatter between people who know way more about the editor and where to stick things than I do, and within the flow of their posts, omitted to make mention of where their scripts were to be placed leaving me befuddled as to what goes where, even if the example was otherwise a good find to solve some settings I want to make use of..

Some examples I would appreciate some more direction on are:

Some settings or house rules have a Skill Rating maximum that is dependent upon the character's Rank. This can be done by making a mechanic that has a Source that has the given setting/house rule set checked.

The example below makes it so that a Novice can only get d8 in a skill rating. It increases to d10 at Seasoned. It increases to d12 at Veteran.

Pre-Traits 5000
Code:
    var xp as number
    var skillMax as number
    xp = hero.child[resXP].field[resMax].value
    skillMax = 4

~Determine the skillMax bonus by XP value.

    if (xp >= 20) then
      skillMax +=1
    endif

    if (xp >= 40) then
      skillMax +=1
    endif

~Apply the skillMax to each skill.
foreach pick in hero from Skill
    eachpick.field[trtMaximum].value = skillMax
nexteach

So where specifically does the above code go? My assumption is that in the editor it's making use of the "Settings" tab, but no matter which area I plugged it into that script failed (i.e. eval, pre-req, etc).

Next one is:

From Caped Crusader, a note about how to make sure someone can take a normal amount of Hindrances if their racial template already gives them one:

Code:
#resmax[resHinder] += 1 (or 2 if it's Major)

Don't even have a clue where the above quoted one goes, is it the "Race", "Racial Property" or "Racial Ability" tab? :confused: And it would solve a major headache I'm running into as PCs inherit a hindrance from their parent (designated as a faction) and one from their Pantheon (designated as a Race), which is blocking the PCs from being able to select more than a single Minor Hindrance of their own choosing.



For the one below, am I correct in assuming this gets made use of on the Races tab? Is it possible to make use of the same code on the Factions tab?

You can do all of the following with an eval script that is Pre-Traits 5000. It is before Calc trtFinal (in the Timing button at the bottom).

To alter the number of Hindrance points that you have is as follows, with X being the value that you want to place there.
Code:
hero.child[resHinder].field[resMax].value += X

I use that because I give so many points in a campaign where I want different races to have varied costs. I then have that racial cost apply against the Hindrance points. This helps to allow races to be their "correct" values and keeps things fair.

For edges, again with the X
Code:
hero.child[resEdge].field[resMax].value += X

For skills, again with X
Code:
perform #resspent[resSkill,-,X,"Free Skill"]
Note that I do not think that the "Free Skill" shows up anywhere, but it helps to recall why it is there when looking at the code.




Also, I'm at a loss at how to solve the following two problems:

1) We decided to use the SPC to render the abilities Scion's have access to, unfortunately upon check marking the SPC-2nd Ed as a source in the configurator, there is a race showing up from it that I don't want included (Atlantean to be exact). How would one go about removing this race for my .user file only? As in, I don't mind it being available for other games if we make use of the SPC-2, but for this setting, we don't want it available.

2) Got to put a disclaimer here first, really really sorry for being so dense in trying to figure this one out and needing my hand held :o I ran across Seely's post here, I had wanted to do something similar to what Seely accomplished, but I noticed it was posted in 2015 and was wondering:
  • are the files he uploaded still required? Or has HL evolved since then to include those features?
  • If I don't need those files, does that change the instructions he posted?
  • On the section with the attribute advancement per rank, how would I go about changing that to every 4 ranks and not every rank?

Finally, I'd like to do grant a extra Edge every X ranks, if this could be dumbed down for me I'd really really appreciate it. I know I'm being asked to be spoonfed here and annoying as hell, but my brain has been beaten to tapioca over the week with the many failed attempts at trying to get something like this to shape up. I got so much stuff floating around in my head and piles of notes to where at the moment, I don't know which way is up.
 
Sorry for loading up another question, but I figured while I was waiting on someone to get back to me with the last one I'd go ahead and work on the powers. I decided that it was more in keeping to make use of the SPC and needed to make a few custom powers.

(edited after discovery, posting in case anyone else runs into a similar problem)

Last night I kept hitting a slew of error messages as I was trying to design a super-power in the editor. The messages read

Attempt to access non-existent containing entity from script
Location: 'eval' script for Component 'SPCPower' (Eval Script #2) near line 3


This error was repeated multiple times in a pop-up on various lines and I couldn't for the life of me figure out why. I must've spent a couple of hours comparing powers from the SPC-2's code to my own, digging through the author kit and wiki wasn't yielding any answers and when I posted my original message last night I was frustrated/salty on the matter and was a little terse in my post.

This morning coming back at it with fresh eyes I noticed something that I missed last night in comparing my power to the SPC's. All the powers from the SPC2 had a gizmo! Looking at it, I saw:

C9.JPG

Surely it couldn't be that I thought. I copied the gizmo as pictured above, plugged it into my custom power and viola, no error messages :eek:

Then I hit the board and edited my message with my discovery. It does leave me with a couple of questions though as I had never mucked about with the gizmo before
  1. why is the gizmo a necessary component for the SPC?
  2. are there any particular things I should be on the lookout with the bootstraps/tags?
 
Last edited:
message #1 -
To prevent the Atlantean race from appearing, use something called a Preclude. You use the ID of the object you want to block plus the Setting ID of the one you want to block it in.

A lot of what Seeley did there won't be applicable anymore. Partly since everything runs on Advances now and not Ranks. Plus some things are already there now, like new Skills costing less to pick up. Seeley also based some of what they did on their own House Rule set so that they were the only one that could use it.

In the trtMaximum example (Eval Script, BTW) I think it'd be easier to run a validation based on Rank rather than messing with trtMaximum.

For the resMax, put that in an Eval Script on PreTraits/5000 on what ever object gives them that ability.

For the rest of these, we have values for all of that in the Settings tab in the Editor now. That's where you adjust those at a campaign level. I think that post was written before we added more detail to the Settings editor.

Am I reading that right? One Attribute Advance every FOUR Ranks? Wow, that's really rough. Are you sure you want to do that? I could probably come up with a way for you, you just have to replace the validation step that checks for that. It just sounds way harsh. You're talking about only getting 1 or 2 changes in Attributes over an entire campaign.

You can set up bonus Edges at each Rank, either by granting an extra Advance point or by adding a creation point and have the player unlock the Hero on the Advance tab to add the Edge.
OK message #2 -
1. There are some things assigned to it later that need the gizmo to be there. It's like a place to hang things from.

2. Bootstraps and Tags are really different. Yes, they both get attached to an item, but where a bootstrap is another pre-existing thing being connected to the target, a tag is just that - a standard text tag that can be read by other processes very quickly. You can use a simple tagis test to see if a given tag is present, plus do things like count them and manipulate them. Tags are really flexible, and should be used whenever possible. Bootstrapping has some limitations, things like bootstrapped gear cannot be removed.
 
message #1 -
Am I reading that right? One Attribute Advance every FOUR Ranks? Wow, that's really rough. Are you sure you want to do that? I could probably come up with a way for you, you just have to replace the validation step that checks for that. It just sounds way harsh. You're talking about only getting 1 or 2 changes in Attributes over an entire campaign.

You can set up bonus Edges at each Rank, either by granting an extra Advance point or by adding a creation point and have the player unlock the Hero on the Advance tab to add the Edge.

Hi CC;
THANKS for reply, I appreciate the time you made to post. Followed your directions for removing Atlanteans, worked like a charm.

As to the above, I should've done a better job of communicating my want. I'm wanting to grant an extra + free Attribute advancement, but schedule it for every 4 ranks.

Then to your 2nd point about bonus Edges at each rank, I've made use of Zarlor's common code thread (that thread is practically my bible, many thanks for all who contributed to it) and have often made use of things posted there in my .user file, but I haven't connected the dots on how to grant something for free based on acquiring an advancement. While I have been slowly deducing things from reading posts/wiki and experimenting, that one continues to elude me :o


OK message #2 -
1. There are some things assigned to it later that need the gizmo to be there. It's like a place to hang things from.

2. Bootstraps and Tags are really different. Yes, they both get attached to an item, but where a bootstrap is another pre-existing thing being connected to the target, a tag is just that - a standard text tag that can be read by other processes very quickly. You can use a simple tagis test to see if a given tag is present, plus do things like count them and manipulate them. Tags are really flexible, and should be used whenever possible. Bootstrapping has some limitations, things like bootstrapped gear cannot be removed.

RE: #2 above
Yes, I'm beginning to discover this, my developer buddy has been walking me through framing one's thoughts to see how tag's are more useful than bootstraps. Up till he did this, I didn't quite grasp their usefulness as a tool lacking the greater context of their value. Basically my approach so far has been very linear and merely aping what I see rather than understanding how to use them. Not saying I'm completely there yet, but getting there.

RE: #1 above
I'm trying to accomplish something with a Faction that following the examples in the tutorial hasn't seen any success with, not sure what I'm doing wrong, and perhaps it's not possible.

I can get my Faction to add things to the Hero by making choices from the menu below the description field without issue. (I.E. Valid Powers, Skills, Edges). But we're using the SPC-2 at Pulp level to represent the supernatural abilities, and I can't get these to show up as choices for the faction.

Example:
I want to give followers of the Faction the Super power of "Attack-Ranged" to represent they're the kid of a god of fire, but none of the Super Powers show up as a valid choice. I've checked the SPC as a source, and attached the same gizmo to the Faction (I.E. SPCPower), but the powers themselves don't appear on the "Valid Powers" list as options. Is this something that's possible to do and I'm just doing it wrong?

Thanks again for the help CC, it IS appreciated :)
 
Well, there's a resource counter that tracks how many Advances a hero has been given called resAdvance. #resmax[resAdvance] is the current maximum, #resleft[resAdvance] is how many are unspent. Four Advances per Rank.

It depends on how you want it to work. Is it dependent on reaching a specific Advance you want want to leverage? (When they reach 6 Advances, x happens).

To give them a free Attribute Die adjustment without messing up their level progression, you'll want to sidestep Advances completely. Add to the resAttrib resource counter and have them unlock their character and choose which Attribute to increase and add it like when they were building the character. You can't add a free Advance because that will also be counted for their Rank since it's all driven by Advances instead of XP's now.

For that you'd have to bootstrap a power to the Faction. The problem here is that unless the hero has an Arcane Background the Arcane tab won't show up. And when you bootstrap the Power, you need to tell it which Arcane Background it belongs to by adding the proper Arcane tag to the bootstrap. Now, I haven't added a Power via bootstrapping it to something like a Faction/Group since we went to multiple Arcane Backgrounds with this latest update. Adding just a Power like that would be the same if you added it to a Racial template. Adding Powers without Arcane Backgrounds has always been tricky because of the interconnected nature of everything. Spells get attached to Arcane Backgrounds, thus having access to Power Points and such like, and the Arcane Background tag tells the Arcane tab to display.
 
Thanks for the suggestions CC, and btw, I'm really grateful HL allows for multiple AB's, that has been extremely helpful in what I'm doing here.

I have a coding question which I haven't been able to figure out, as I'm not sure where to find my answer, probably a eval rule/script?

I've been making use of Precludes to "trim the fat" from my .user file to hide a number of things that aren't appropriate for the campaign, but now I'm in a unusual fix to customize elements from the SPC where Precludes are too all or nothing.

What I want to be able to do is selectively eliminate generic modifiers (i.e. Invent, Device, etc.) from specific powers, but not from others. Any suggestions?
 
You should be able to set up a Mechanic to do this. Create a Mechanic, and assign it to your source. This way it runs for each character with that Source. Add an Eval script to it to do the work you need.

Then in the eval script cycle through the Powers with a foreach. You just need to go through and find the powers you want to alter this on, and delete the SPCPwrMod tag associated with the Mod you want to remove from that Power. The generic tags get assigned at Initialize/500 so you need to do this after that timing-wise. Here's one that will remove the first level of Device from the Armor Power...

Code:
      foreach pick in hero where "component.Power"
        if (eachpick.tagis[SPCPowers.s2cArmor] <> 0) then
          perform eachpick.delete[SPCPwrMod.s2mDevice1]
          ~ you can do more of these deletes to remove other Modifiers
          endif
        ~ you can add more if statements to check for other Powers. Only do the foreach once, they are expensive 
        nexteach
 
Last edited:
CC: Thanks Brother, made use of your suggested code and does what I need it to. However I'm a bit confused on a couple of points and was hoping you had the time/inclination to provide clarity/guidance.

In your remark, you said "Only do this once, they are expensive", I'm assuming you're referring to how much effort HL has to do to process such things, and that if I have too many in the .user file that it makes the tool sluggish. What I'm confused on is where the suggestion of restraint factors in, is in how many Mechanics I create or how many powers I want to hide modifiers from?

Tangential to the above question, lets say I have 10 powers that I want to preclude two power modifiers from. For the sake of clarity, lets say i want all 10 of these powers to not be able to access the Switchable modifiers of Primary/Alternate. And lets say that on 3 of these powers, I also don't want them to be able to choose the "Limitation 1/2" power mods.

Do I:
A) Create a mechanic for each power separately, I.E. create a mechanic for power #1, then the same mechanic but for power #2, etc?

B) Put all 10 powers in one eval script?

In anticipation that your answer is B, I'm not sure if my understanding of script writing is proper so a quick example to see if I would be doing this correctly or if it makes you fall off your chair laughing hysterically ;)

Code:
foreach pick in hero where "component.Power"
        if (eachpick.tagis[SPCPower.spcSCFire] <> 0) 
        if (eachpick.tagis[SPCPower.spcSCBeast] <> 0)
        if (eachpick.tagis[SPCPower.spcSCBeuty] <> 0)
        if (eachpick.tagis[SPCPower.spcSCChaos] <> 0) 
then
          perform eachpick.delete[SPCPwrMod.s2mSwitchB]
          perform eachpick.delete[SPCPwrMod.s2mSwitchA]

          endif
        nexteach


Again, assuming your answer is B above, assuming that powers 8-10 have 2 additional power modifiers to be excluded, do I write the script as follows?


Code:
foreach pick in hero where "component.Power"
        if (eachpick.tagis[SPCPower.spcSCFire] <> 0) 
        if (eachpick.tagis[SPCPower.spcSCBeast] <> 0)
        if (eachpick.tagis[SPCPower.spcSCBeuty] <> 0)
        if (eachpick.tagis[SPCPower.spcSCChaos] <> 0) 
then
          perform eachpick.delete[SPCPwrMod.s2mSwitchB]
          perform eachpick.delete[SPCPwrMod.s2mSwitchA]

          endif
foreach pick in hero where "component.Power"
        if (eachpick.tagis[SPCPower.spcSCFire] <> 0)
        if (eachpick.tagis[SPCPower.spcSCBeast] <> 0)
then
          perform eachpick.delete[SPCPwrMod.s2mLimit1]
          perform eachpick.delete[SPCPwrMod.s2mLimit2]

          endif
 
        nexteach
 
What I meant was you only need to do one foreach loop. You only need to go through the Powers once.

It can't do stacked if's like that. However, one advantage of tags is we can do this:

Code:
if (eachpick.tagis[SPCPower.spcSCFire] + eachpick.tagis[SPCPower.spcSCBeast] + 
        eachpick.tagis[SPCPower.spcSCBeuty] + eachpick.tagis[SPCPower.spcSCChaos] <> 0)  then

Since all you are looking for is if any one of those tags is active.

And then just put in another if statement for the next group of Powers... In your example the second if can go inside the same foreach loop. No need to do a second one.
 
CC, thanks Brother, your guidance has been a great help! I won't be so presumptuous as to say I now have full command of these "Ifs", but I'm getting there :)

So hopefully I'm not turning into a pest (too late? :o) but I got another issue i can't figure out. I've had to create some custom content for the SPC, there are some things in SW that are either arranged somewhat silly to my sensibilities, and I wanted to add more choices/effects. I'm having the same problem showing up on each custom power set, but I'll illustrate it via the following example:

Immunity Poison, Disease, Ageless, all seem to me to be related and should be part of a table like Heightened Senses has enhanced senses. I'm influenced by M&M way of doing it, so I created a power called "Immunities", wrote up the 3 just mentioned and about a dozen more, attached them to the Immunities power and it loads and allows players to choose what immunities they have without any problems except one. I keep getting the same error message reading "Immunities: A power level must be selected via the chooser", flagging the table red on the character sheet.

Heightened Senses was my guide (especially as I created my own version of super senses to replace it and its got the same problems) with a micro comb, I mimicked its structure and how the power modifiers are coded in the editor exactly, and that warning refuses to go away. Things I've done are:

Name: Immunities Unique ID: spcMRimun Uniqueness; No Gizmo: SPCPower

Just like with Heightened Senses, everything else beneath the "Summary Text" is blank, i attached via the "Power Modifiers" the various powers to be included, specified my two sources: SPC and the HouseRule.user file. My tags consist of all the power mods I created for table, including copying a tag from Heightened Senses with the following properties:

Group ID: thing Tag Id: holder_top Name: Top Holder Abbrev: ???

I even mimicked putting the above tag at the very bottom of the tag table, double-checked my spelling, even resorted to doing a copy/paste in each field of the tag just in case there was something I couldn't see. Then I mimicked how the power mods for Heightened Senses were constructed, all of them have the "Add" operation, a numerical entry in the "Value" field, same sources, and "Uniqueness" set to Unique.

At first, due to the warning message, I figured "Oh, look in the SPC Power Levels" tab dummy, copy what Heightened Senses did there. I know how to add power levels to a power, I've constructed several such powers (though they're simplistic, very little in the way of scripts or rules) and went looking for examples in that tab, but Heightened Senses isn't present, so near as I can tell, it's unnecessary. So what the hell am I missing?:confused:
 
OK, the reason you are getting that error message and Heightened Senses doesn't is because there is a specific exception in that validation for Heightened Senses. I never considered someone wanting to set up another power with the same structure. I'll change it to look for a tag instead next time I work on it, but that doesn't help you now.

I can't think of a work-around that doesn't mess it up. That validation message will just need to be ignored.
 
Last edited:
That exception is on Heightened Senses and Super Skills for different reasons. Heightened Senses works where each additional Sense is counted as another Power Level, so no initial point cost and no set power levels (1, 2, 3...). Super Skills is because no matter how many new Skills or Skill modifiers the hero takes, they count as a single Power for the purposes of Modifiers. Hence the 0 point cost for the Super Skill Power itself, and no Power Levels. Usually a 0 initial point cost means the Power uses Power Levels. It was only these two that violated that rule, so I exempted them specifically. I've added the SPCPwrType.SkipPwrLvl tag to cover this and added it to the all the applicable places in the version of the code here. So when the next update gets released you can use that to disable that message and also stop the Power Level chooser from showing up.
 
Back
Top