• 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

Authoring Kit - List of Wiki Errors?

What did you change on tab_basics? What does your code to display this field look like?

I only changed the [trtFinal] to [trtDisplay] within the template as instructed.

Code:
  <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>

Copied straight from my file.
 
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.
 
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.

From the tutorial
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.

Both links are broken.

I already KNOW that the bitmap symbols aren't supposed to be there, it is supposed to read "d4", "d6", "d8", etc as text.

Also, The floating info window is only covering the derived stats from the skeleton files and does not apply to this question. Those values aren't even discussed until two pages down which I just started working on while waiting for replies here.
 
Sorry about the links - if a web address posted on this forum ends in a parentheses, the close parentheses is left out of what's entered if you click on that link. You can manually edit the address it takes you to in order to fix those. Just add a close parentheses to the very end of the address.

The steps being done on this page of the walkthrough will not actually change the look of the numbers within the incrementers on the basics tab. At this point in the walkthrough, it is only doing the initial work that will support later changes that will alter the way the incrementers display their values.
 
Then why does it work for the other tables? Also why has the tutorial existed for so long telling you that it IS supposed to?
 
Last edited:
Those other tables are places where you're only displaying a value, not allowing the user to set a value. The way you need to code displays are generally simpler than coding for things the user sets. So the walkthrough doesn't get to the more complex parts yet, since it's still at the beginning.

What that page actually says is:
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.

It does not say that it is actually changing the finalize script it refers to - just that it's setting up a field whose results will be used in that finalize script.
 
Actually it does...
After our data files get more fleshed out, we can replace the simple "d6" notation with a suitable bitmap for the die type.

also below it says...
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.

and the page(adding bitmaps) you sent me to even confirms that it is supposed to be working before you get that far into the tutorial.
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...

This needs to be addressed. Either by error checking the tutorial line by line, by going thru it slowly as a new file author would or by cleaning up the page entirely.

Look at this from the customer's (my) viewpoint for a moment. Their are two references to the notation working on the traits page, and then the customer is told that they need to go halfway thru the tutorial to play with bitmaps, which, for the record I never expected to work at all yet, nor asked for help on.

Then I am told that the page is wrong when it tells me the notation should be working and that the notation starts working at the bottom of the traits page, but then it doesn't.

Next, I am asked to post code, which is good, until I am told I am reading the instructions wrong using an example that also states the notation should be displaying in text.

I have spent over a week looking for a problem and many days patiently waiting for help that does not get looked at until I rephrase my question (which in turn bumps the link to unread status). When you do look at it, the response indicates they didn't fully read my post.

My attitude this whole time has been based in trying to help others that might be going thru the tutorial, until the feelings of having wasted vast amounts of time, and being told that I should have deciphered the vague instructions regardless of what the rest of the pages say. I am doing my best to be diplomatic, because I wish to continue with this project, and also because exhibiting harsh critique is the preferred excuse for modern customer service groups to sever contact with a customer. I hope that isn't the case here. I understand that Realm Works marketplace launch may be drawing more of your time but the authoring kit is also one of your products. I think it a great product, I think every RPG or GM out there should use it. The current state of the wiki detracts from this belief. I would like to help improve that.
 
Well, I decided to continue on. I got to the 10th page "Races and Racial Abilities (Savage)" and then ran into this problem. This happened on the first section of the tutorial where you add the Atlantean race to the files. This warning pops up every time you click an incrementer to adjust stats. No warning from the compiler.

xaGY8JG.jpg
 
I apologize, but I'm hoping to have a release for Shadowrun finished by the end of this week, but that's going to take a lot of my time this week, so I won't get a chance to study these issues in detail until next week, but the error message in your screenshot is something to do with the statblock. sbtraits is a procedure that a lot of different things in the statblock call, so just looking at line 9 may not be useful - if I remember correctly, that procedure uses a foreach to search a list of things. So what it looks like is happening here is that the procedure is finding things that it hasn't been set up to handle yet.
 
Dead in the water. I said I would push on but then this happened...

Character Creation Logic (Savage)
http://hlkitwiki.wolflair.com/index.php5?title=Character_Creation_Logic_(Savage)

Attribute Points

Code:
<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>

Get the compiling error, "Syntax error in 'eval' script for Component 'Atrribute' (Eval Script '#2') on line 3 -> Incorrect parameter count for macro reference in script". It didn't look like any of the macros used up to this point. First looked at the source file and tried using that, got same error, put it back to the line from the tutorial above. Then looked at the macro under definition.dat found this...

Code:
<scriptmacro
    name="resspent"
    param1="resource"
    result="hero.child[#resource].field[resSpent].value"/>

Then I decided to look at the one under the source files...

Code:
<scriptmacro
    name="resspent"
    param1="resource"
    param2="oper"
    param3="value"
    param4="text"
    result="hero.child[#resource].field[resSpent].modify[#oper,#value,#text]"/>

A rather large difference from the skeleton files, with no coverage leading up to this in the tutorial. Did changing this work? No! It gave me a plethora of warnings from all over files. Changed it back. This is getting painful.
 
Last edited:
Decided to get some sleep and come back at the macro problem today today. What to do when a macro doesn't work? When in doubt, tear the macro out...

Code:
hero.child[resAttrib].field[resSpent].value += (field[trtUser].value - 2)

Not sure this logic is good, but it seems to be working.
 
I really wish I had read this thread before purchasing. Sadly, neither this thread, nor the wiki is current. The offline PDF links do mention that the PDFs may be out of date with the wiki, but there is a reasoned, entry-level presumption that the wiki would not also be profoundly (half a decade) stale.

Had I done my due-diligence and not assumed maturity in the documentation, it is highly unlikely that I would have purchased -- and, having experienced this buyer's remorse, I feel obligated to caution others and coach the leadership team.

The ability to customize is one of (if not the) flagship cornerstone(s) of this product. The fact that there is a significant barrier to entry that is self-inflicted by Lone Wolf Development is disappointing. Documentation is as important as the product itself. The amount of focus upon and the investment in product documentation that is meaningful and actionable is a direct reflection of management commitment to providing a satisfying customer experience.

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.

You recognized the challenge. You concluded and you took action. Then you stupendously dropped the ball. I now note after the fact, that it does not say "we can revise and extend on an ongoing basis." First impressions are lasting impressions and contribute to the "word-of-mouth" narrative. In the spirit of coaching, I waggle-my-finger shamefully. You can do better. You must do better.

There is no forward looking initiative, burn-down, or deadline that should ever stand between development and documentation. While the "business case" for mature documentation is often obfuscated by myopic, short-term interests, the business case for responsible documenting exists and is compelling. A product is only as complete as is its documentation.

A stupidly silly example that makes my point spectacularly, on the front page (http://hlkitwiki.wolflair.com/index.php5?title=Home):
Hero Lab is Copyright © 2006-2009 by Lone Wolf Development, Inc. [...]

While legally unnecessary, you initially cast your copyright notice in the long form; however, you have not found the time/resources to update a simple date annually! Out of a work year consisting typically of 2080 hours, no one, anywhere in your extended organization of employees or associates could find the couple minutes to edit a single item on the customer-facing front page to the principle documentation for the Authoring Kit. This isn't a legal matter, it's a matter of perception. It is a perception of abject laziness and irresponsibility. How can anyone believe you are serious about supporting a product that you can't be bothered to change a couple digits once a year?

Details matter! Either you want to best-in-class or you do not. Or to be crude, "defecate or perform egress from the evacuation station." Half-measures avail nothing.

Make no further excuses. Apologize and make to do better. Or not; it's your brand.


While I'm in for a penny, I can be thankful that the method of entry (store setup) only allows a single initial purchase. As it is, a couple 10'ers is largely well within my pain tolerance [EDIT] for a boondoggle.

That said, despite my dissatisfaction with Hero Lab, I am enamored with Realm Works. The alleged synergy between HL/RW intimated potential time savings; therefore, I had hoped to leverage both tools to uplift my game. Unfortunately, to make use of Hero Lab requires an investment of time in reverse-engineering that steals time away from the actual creative process of story design and gaming. I don't disparage those for whom meta-gaming brings great joy. I simply would rather game than meta-game.

There are suitable substitutes in the market for custom character and npc management that are more closely aligned to my requirements. I'm profoundly grateful that I discovered the tragic state of the dilapidated documentation before investing further.[/EDIT]

Despite my assertive tone, I am not angry. I would not have taken the time to be explicit if I did not have some belief that you can do better. I simply don't know if you want to do better.

Z
 
Last edited:
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.


Dave
 
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.
The non sequitur and your confusion not withstanding, I deeply appreciate such a lovely welcome. :)
 
Glad my thread could be of assistance, I suppose.

I feel Hero Lab author kit at this point was a bit of a waste of time and money (way more time, than money). It takes so long to work thru the horribly out of date and broken tutorials while trying to imagine how to apply it to your own projects if and when you ever reach the finish line of the wiki.

Reverse-engineering is quite apt in describing the experience, and while you can come to these forums for help most of the time your ignored or put on the back burner because some new module needs to be released. 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.
 
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.
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).

The time and effort needed to work with Hero Lab Authoring Kit is better served actually learning C# or Java and/or going bespoke. All the eye candy is worthless (if not an actual drain and distraction on game design) if it one can not efficiently achieve meaningful and actionable results that contribute in a meaningful and actionable way to game play.
 
Back
Top