Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
What did you change on tab_basics? What does your code to display this field look like?
<template
id="baTrtPick"
name="Trait Pick"
compset="Trait"
marginhorz="16"
marginvert="3">
<portal
id="name"
style="lblLeft"
showinvalid="yes">
<label>
<labeltext><![CDATA[
@text = field[name].text & ":"
]]></labeltext>
</label>
</portal>
<portal
id="details"
style="lblLeft">
<label>
<labeltext><![CDATA[
@text = field[trtDisplay].text
]]></labeltext>
</label>
<mouseinfo><![CDATA[
~insert appropriate code to explain how the trait was derived
@text = "???"
]]></mouseinfo>
</portal>
<portal
id="info"
style="actInfo">
<action
action="info">
</action>
</portal>
<position><![CDATA[
~set up our height based on our tallest portal
height = portal[info].height
~if this is a "sizing" calculation, we're done
doneif (issizing <> 0)
~position our tallest portal at the top
portal[info].top = 0
~center the other portals vertically
perform portal[name].centervert
perform portal[details].centervert
~position the info portal on the far right
perform portal[info].alignedge[right,0]
~position the name on the left and give it some reasonable space
portal[name].left = 0
portal[name].width = 135
~position the details to the right of the name and the left of the info portal
perform portal[details].alignrel[ltor,name,10]
portal[details].width = portal[info].left - portal[details].left - 10
]]></position>
</template>
The things you circled in red were not supposed to have been changed into dice displays at this step of the walk-through.
This page: http://hlkitwiki.wolflair.com/index.php5?title=Incrementer_Behavior_(Savage) is where the size of the incrementer is changed, and this page near the end: http://hlkitwiki.wolflair.com/index.php5?title=Using_Bitmaps_for_Die_Types_(Savage) is where the bitmaps to show them as dice are put in place.
The things that were changed by the code you posted I think are hidden under the floating window in your screenshot.
Our script gets the final value for the trait and multiplies it by two to yield the proper die type, which can be output with an appropriate notation (e.g. "d6"). After our data files get more fleshed out, we can replace the simple "d6" notation with a suitable bitmap for the die type.
The text for the "trtDisplay" field needs to be generated prior to its use in the Finalize script of the "trtUser" field. The problem is that a field with a Finalize script cannot use the finalized value of a different field. The solution is to use a script that is timed to occur very late in the evaluation process. Since we can only compute value-based fields in a Calculate script, and we need to synthesize a text-based field, we must generate the text in an Eval script. Our script gets the final value for the trait and multiplies it by two to yield the proper die type, which can be output with an appropriate notation (e.g. "d6"). After our data files get more fleshed out, we can replace the simple "d6" notation with a suitable bitmap for the die type.
After our data files get more fleshed out, we can replace the simple "d6" notation with a suitable bitmap for the die type.
Once everything is in place, reload the data files and test everything out. The sample attribute should display as "d4" on the Basics tab. If you adjust it up and down, it should properly display the next die type, capping at "d12" at the upper end and "d4" at the lower end.
Overview
The contents of the attribute and skill incrementers currently show the die-type and any adjustment using the format "d6+2". It would be ideal if we actually showed a bitmap for each die-type...
<eval index="2" phase="Traits" priority="10000">
<before name="Calc resLeft"/>
<after name="Bound trtUser"/><![CDATA[
~since the base starting value for each attribute is two, we add only the extras
perform #resspent[resAttrib,+,field[trtUser].value - 2,field[name].text]
]]></eval>
<scriptmacro
name="resspent"
param1="resource"
result="hero.child[#resource].field[resSpent].value"/>
<scriptmacro
name="resspent"
param1="resource"
param2="oper"
param3="value"
param4="text"
result="hero.child[#resource].field[resSpent].modify[#oper,#value,#text]"/>
hero.child[resAttrib].field[resSpent].value += (field[trtUser].value - 2)
The Authoring Kit for Hero Lab provides a vast array of capabilities, which will continue to evolve with the product. As such, we needed a means of documenting all those capabilities that could readily adapt and evolve as well. We concluded that the best way to accomplish this is to create a wiki that we can extend on an ongoing basis.
Hero Lab is Copyright © 2006-2009 by Lone Wolf Development, Inc. [...]
The non sequitur and your confusion not withstanding, I deeply appreciate such a lovely welcome.I'm confused what the authoring kit has to do with Realm Works? Oh, and since this is your first post, welcome to the forums. When I was creating the ruleset for Castles & Crusades, these forums were priceless.
QFT! A tool stops being a tool when using it becomes an end in itself. Buying into the authoring kit is a dive into the deep end of the pool; it is a distraction that pulls one away from the mission of gaming and presses one into the mission of development for development sake. I don't/won't knock such if such is one's thing... I simply would rather spend more meaningful and actionable time gaming (than meta-gaming).Eventually other things and projects must be attended to in your life and the lack of support for the authoring kit makes it easy to put aside for another year until you get the urge to try again.
Then, of course, you come back to it and find that instructions are STILL older than Sanford and Sons scrap yard. Every time I look at that wiki I can hear the theme song.