Gizmos and how to use them
Every pick in Hero Lab must be within a container (this isn't a container like a backpack - this "container" is purely a programming term) (the mechanism Hero Lab uses to track what items are within what packpack or pouch is referred to within the code as "gear holding").
In the vast majority of cases, that container is called "hero". That's one of the two types of container in Hero Lab - the other type is called a gizmo. Unlike the hero container, where there's exactly one of them in each character, there can be as many or as few gizmos as you need to build your game system. All gizmos are attached to picks, and their purpose is to allow complex customizations of that pick. For example, in Pathfinder, they're what allow you to customize weapons and armor with materials and item powers. They're also used to build metamagic-modified spells - adding the various metamagics to a base spell. In Shadowrun, where nearly every piece of gear is customizable, with a variety of options available, nearly every piece of gear has a gizmo, so that Hero Lab can support that customization. The same sort of manipulations you're used to using on the hero container are also available within a gizmo. Just remember that you have to go to the pick that the gizmo is attached to first (most often, when dealing with gizmos, you'll be starting on that pick, or on one of the picks inside the gizmo, so that's normally not a problem). The code used when dealing with a gizmo is slighly different if you're coming from the pick that contains the gizmo, or if you're coming from a pick within the gizmo. From the overall pick, to get to the gizmo: gizmo.child[XXXXX] foreach pick in gizmo From a pick within the gizmo - this would be used if you wanted to manipulate something else in the gizmo - a prereq, for example, where you have to add one item to the gizmo before you can add another: container.child[XXXXX] foreach pick in container You can also go from a pick within the gizmo to the pick containing the gizmo: parent Even within a gizmo, the "hero" transition still works, and will take you to the hero context. So does herofield[XXXXX]. |
The first step in setting up a gizmo is to write the <entity>. Here's an example from Shadowrun:
Code:
http://hlkitwiki.wolflair.com/index....Element_(Data) Entities are placed in .str or .core files (wherever you're placing the component that will use them). They go after all the <component> and <compset> elements in that file, so they're usually going to be the very last thing in that file. The next step is to add that entity you've just defined to a thing: Code:
<child entity="adjPossess"> Here's the wiki page for the <thing> element, in case you want to look up the exact details of adding a <child> element to a <thing> element: http://hlkitwiki.wolflair.com/index.php5/Thing_Element_(Data) Since it's normal for everything in a compset to use the same entity, here's an example of an editor entry that offers a checkbox - if the user checks that box in the editor, that <child> will be added: Code:
<inputthing If you don't even want to offer the editor user a choice of whether they're going to add a particular child, set that at the top: Code:
<editthing If you have set a defchild="", you can use the target="child" option on tag and bootstrap options to set up bootstraps that will be within the gizmo, as opposed to normal bootstraps that will go inside the same container as the pick itself, or tags that are assigned to the gizmo (the container)(setting up tags in the gizmo is useful for prereqs, the same way setting up hero tags is useful for prereqs for things in the hero container): Code:
|
Now, the visual elements - showing that gizmo to the end user.
Here's an example from the gear tab in Shadowrun - this is within a <template>, and that template is the picktemplate="" of a table_dynamic portal: Code:
Now, scroll back a little ways in this thread - find where the <entity> was defined. See how it has a form="" option? That's where you set which form gets opened when the user clicks that button. Here's how to define a form: Code:
<form 700 (or smaller, if you don't need it very wide) is the widest I'd recommend making a form. There are some netbooks and old computers out there whose screens are only 800 pixels wide, and we want Hero Lab to be able to support those. Too much wider than 700, and some of your form can end up off-screen. If you need lots of space for your form, think downwards - make it taller, and use a scrollbar to let the user see everything. Normally, forms go in files named form_XXXXX.dat |
Using gizmos along with the purchasing mechanisms (if the gizmo represents a piece of gear that you can purchase modifications for, using cash).
If you want the things you add to your gizmo to cost money, you'll need to add the thingbuytemplate="" option to your entity: Code:
<!-- The Customizable gear entity --> Then, in visual.dat, add a new template - this will automatically be placed along the bottom of your form, so that users can say OK when they're done purchasing all the stuff, and they won't actually be charged cash until they're done: Code:
|
By default, when the user adds a thing that has an entity added to it, the form will automatically pop up.
You can change this behavior by setting a flag on the main component you are using for the picks that contain these gizmos. Note that the component you add it to must be the same component listed as component="" In the table where you're adding the items that have the gizmos. The options are: addbehavior="default" addbehavior="customize" addbehavior="never" Not setting this flag is the same as addbehavior="default". Under this setting, the customization form always opens when you add this type of item. customize means that when users are adding or purchasing these customizable items, they'll see an extra button at the bottom, instead of just "Add", "Add and Close", and "Close" - they'll also see "Customize". If they choose customize, the form will show, but "Add" and "Add and Close" will not show the customize form. never means that the user won't have the option to customize it immediately after purchasing it. They'll have to edit the item later. |
(#3 Reserved in case I think of anything more I want to add)
|
A detail I forgot to note:
Note how all my gizmo examples had a helper pick? That's because of a change that needs to be made to tables within a gizmo. Normally, you can leave the addpick="" part of a table_dynamic blank, because it defaults to addpick="actor". But in a gizmo, there is no default available, so you must have an addpick="". So, I always add a helper pick, and set the addpick="" to that helper pick. Without an addpick, the additem text will always be ?????? The helper pick doesn't need to be complex - you can use the Simple compset that's defined in miscellaneous.str for that pick, because it doesn't need to have any behaviors of its own - it just needs to be present. |
All times are GMT -8. The time now is 03:52 PM. |
Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.