• 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

Is it possible to...

Hmm... I'd guess you would need to have a Tag like they do for Equipment (Group: Hide, Tag: Edge, i guess?) Since we use that method (well, with Tag: Equipment), to do things like hide, say, a thrown version of a spear from being bought but so it will still show up on your weapons list because it was bootstrapped to the melee version of that weapon (and usually vice-versa). You might add that as a request here: http://forums.wolflair.com/showthread.php?t=13330. I've not had a need to do that yet but it might be useful not only for what you're working on for it sounds like it might be helpful for Savage Rifts as well so that may be useful to add it if it can be done.
 
Ok, I think that I have things working via a pre-req script. I will deal with any live usage considerations later; for now, I think that I should be able to get the character building completed without much more fuss.

I have pushed all of the custom edges into a STREETS OF BEDLAM division. I doubt if this is common, but the author didn't really specify the types of the edges and I like being able to find all of the setting specific edges in one place anyhow. This helps mitigate some of my unhappiness with not being able to hide list items.

As it turns out, pre-req scripts override the ONLY ONCE setting for edges - which I regard as a bug. If the edge is set to UNIQUE, it works as expected. I am not sure what the logic here is, but I am guessing that there is a reason for this. For my intent, there is no significant difference between ONLY ONCE and UNIQUE.

Top

Sample pre-req code should it matter:
validif (hero.tagis[Group.grpBEDbacr] + hero.tagis[Group.grpBEDbasn] <> 0)
 
.... And then I ran into the archetype that allows the character taking it to start with a d6 in vigor.

So far, I am not finding a good way to add it, much less a way that will automatically remove it when the archetype is abandoned.

I did get several archetypes added and pretty much working (one has an option to worsen a hindrance and worsening a bootstrapped hindrance gets you zilch.)

I will see if you fellows have any suggestions, but I am close to taking what I have learned and moving on to something a bit more suited for a greenhorn :)

Top
 
Yeah, you are getting a bit into the weeds, but the common code thread definitely has the answer for you adding to an trait die. Although, the common method is to use that for a skill rather than an attribute and no attribute will ever be below d4. In essence the effect of the archetype is to add +1 die type to Vigor UNLESS Vigor is already d6 or higher, correct? In that instance you would just have to enclose your +1 die type in an if statement, is all. You just need to make sure you get the timing right. It will probably need to be early, so I'm guessing something like Pre-Traints 3000? I'd have to play to figure that one out.

Removing that bonus... first off to characters change archetypes all the time in that game or something? If not, then no problem, if they do then I would think that if you changed the archetype that code would go away and that code would only apply itself while that archetype were active. If it's pulled it should pull the extra die with it... maybe. I mean once you advance a boosted Vigor it would no longer be a d4 at the base... Hmm... that almost makes it more like a Super Attribute in effect, which would be something activateable. I couldn't really tell you off the top of my head, though, i think I'd have to play around to really figure that out.

I would only add one more comment, though, which is that it's sometimes fine to just not automate everything through HL. Sometimes you just make a note in your descriptions to tell the player to do the thing they need to do.
 
Yeah, you are getting a bit into the weeds, but the common code thread definitely has the answer for you adding to an trait die.
....
Removing that bonus... first off to characters change archetypes all the time in that game or something?

I will look up in the common code thread then.

I think that, as part of exploring archetypes, a hero lab owner might select multiple archetypes just to see what they offer. Shopping for a character might create some unexpected messes.

Thanks for pointing me towards the traits boost :)

Top
 
So under BOOTSTRAPS, I find...

IHR8dJh.png


That I can select the Vigor attribute directly. I can then go into fields and ASSIGN a value.

xk2kwrz.png


trtBonus doesn't seem to have an impact. Is there a different name for the field that holds the value of vigor (or other attributes for that matter)?

This looks right - I just don't know that trtBonus is the right field.

Thanks!

Top
 
So the Eval Rule gets it done...

hHVTr1G.png


Coincidentally, it also removes the extra point of vigor when changing archetypes and will not allow me to spin it back to a d4, so it is a real win.

Still curious if it can be directly assigned by assigning a value in the bootstrap, though obviously this is less of a concern now :)

Top
 
Bootstrap wouldn't work because "Vigor" already exists, there is nothing for the program to bootstrap (or ADD, if you will), the best it could hope to do would be to overwrite and it's not built to do that for plenty of good reasons. So you need to use an eval script like you did to modify the value instead. I figured that would work as you suggested but I guess my concern would be how it would affect things if Vigor were already d6 or higher. With the script you have above it's fairly clear that it will just add a die type to whatever the current value is (or remove that if the archetype is changed) but that also means it does not properly address if that archetype is only supposed to boost Vigor to d6 but no higher.
 
No, I don't think you don't should bootstrap the attribute like that.

Also, don't do a foreach there. Foreach is very costly, performance-wise.

Try these (with Attributes it a bit different than Skills):

Code:
#traitinplay[attrStr] += 2
#traitbonus[attrStr] += 2
 
Thanks for the explanation and examples, guys.

I have been in contact with the author. While the setting book doesn't explicitly state it, the author confirmed that it was his intention that taking all archetypes (except, of course, one of them), would result in no bonus for being human.

My problem is that I don't even know what the bonus points for buying edges and the like are named. I will probably add the code to deduct the point at the same place I was augmenting vigor, but at least I had a word (vigor) to search for and knew that it was an attr class element when looking for the controlling unique ID. For these points, I am completely in the dark about how to refer to them inside HL.

Removing the free edge for being human is that task. I suspect that it is tied up in a RACE (Human) and perhaps my best option is to create a doppelganger race without the perk that gets bootstrapped. (Not at home now and just musing.)

Top
 
Good call, I was thinking that as well.

I noticed that edges had a flag for use only during character creation and thought it odd that hindrances did not have a similar flag. That's the only thing I've noted thus far that I thought should have a mirrored feature.
 
Look at the Racial Ability "Bonus Edge" (abFreeEdge). It's what adds that free Edge. It does it like this:


Code:
      hero.child[resEdge].field[resMax].value += 1

To subtract:

Code:
      hero.child[resEdge].field[resMax].value -= 1
 
That being said, if you need Humans to not have that free Edge, your supposition is correct. The best way to handle that is to create a new Race record for Humans for your Setting and preclude the racHuman version.
 
That being said, if you need Humans to not have that free Edge, your supposition is correct. The best way to handle that is to create a new Race record for Humans for your Setting and preclude the racHuman version.

Thanks, Caped! It seems easier to just add a point once than to subtract it 14 times (15 archetypes, one of which is just a normal character called a Citizen).

It will also encourage character builders to fully engage the archetype system - which is important to this setting.
 
Man, you'd think that I would get a little wind in my sails and not crash into another problem, but no such luck.

I have run afoul of an archetype that has an edge that gives it two knowledge skills. Each at a d6. I need to 1) assign the two knowledge skills, 2) get them to a d6, and finally, 3) replace 4 points in the skill buying fund pool. :eek:

I have already figured out that I don't need to make the edge do the work; I can just assign a pair of knowledge skills from the archetype group pick list. However, that might not be efficient if I want to go up to a d6. I dunno.

I am starting to think that I should scout a head to see what sort of devilish torment is in store next for me... The only upcoming obstacle is one where the player can make a A/B choice between SHOOTING or FIGHTING. Shame we cannot present a menu :(
 
I'm guessing you haven't really looked at the Common Code Examples tread yet. Your answer is the very first code snipped listed. ;) (EDIT: errr... 2nd code snippet, since this is for Knowledge skills).
 
Last edited:
OK, here's a workable solution for the Knowledge Skill bit. I solved this in Racial Properties. You'll just need to create Racial Properties to add the two knowledge Skills, and then bootstrap the Racial Properties to the Faction. There's a template already in place to do this in Racial Properties. Do a Copy, and and search for Know. You'll see it. There is one catch, though. You'll need to create one of these Racial Properties for each Knowledge Skill. This is because there a place to record which Knowledge Skill it applies to, and it has to be preset for the bonus to work. Since Knowledge Skills are completely open-ended, it's impossible for us to create them before-hand. The issue is that there's otherwise no way to handle two specific Knowledge Skills getting the bonus. That Domain has to be listed somewhere.

This example allows the Domain to be accessible from the Editor interface itself, and not in the eval script. If that matters.
 
Last edited:
Back
Top