Joshua Stream Pre
View RSS Feed

Minty23185Fresh

A Neophyte Tackles the FG Extension - Visibility, More Options Please

Rate this Entry
Play testing the Effect Visibility Extension indicated more visibility options are required. When effects are only visible to the GM, if a player applies an effect to their character and doesn’t see it in the Combat Tracker, they tend to apply it again, and then again. When the GM views the player’s character in the Combat Tracker, the self applied effect could be listed 2, 3 or more times.

What additional options are needed? Certainly, an option that allows the player to see effects applied to their own character (“self”). Plus an option that allows the player applying an effect and the target of the effect to see it (“target”). I’ll start by implementing these two additional options.

Detour: A note about consistency. As I work through the steps of creating an FG extension I am trying to be mindful of consistency. Using object names, folder names and folder placement, and even programmatic indentation consistent with the rulesets. After all, I am creating an extension of FG’s functionality. If it were my application I could go off on whatever willy-nilly, haphazard naming scheme I like. It seems only prudent to be courteous to others coming behind me to provide a seamless programming style between the rulesets and my extension rather than subject them to my individuality.

Recall from a prior blog that I had located the XML file where the Combat Tracker’s effect visibility button is defined. For each new state of the button I’ll need a named icon, a tooltip, and an associated graphic (the button face). I’ll go through this process by creating new .png graphics files, then creating <icon> definitions to reference them. I’ll define tooltip strings and sew everything together with button <state> definitions.

First the graphics that will show up on the button for “self“ and “target“. As a start, I wanted to find the .png graphics files for the current button faces, then in a graphics editor like Paint, change the lettering and save them in new files.

Using Notepad++, I searched for the <icon> names in the 5E and CoreRPG rulesets. That led me to the graphics_icons.xml files and then to the graphics\buttons subfolders. Looking through the graphic files in the folders I discovered button_toggle_self.png and button_toggle_trgt.png files. Unbelievable luck - it’s as if someone started this project but didn’t finish it.

Next I searched for the new-found file names in the rulesets to see if they had already been assigned to <icon> names and they were, in the graphics_icons.xml file.

All that was left were tooltips. I looked in some of the XML files that have other Combat Tracker tooltip strings defined but I found nothing relevant, so I created a strings subfolder in my extension folder. I then put the following definitions in a new strings_5e.xml file:
Code:
<?xml version="1.0" encoding="iso-8859-1"?>

<root>
  <string name="effect_tooltip_visibilityself">Visible to GM and Self</string>
  <string name="effect_tooltip_visibilitytrgt">Visible to GM, Self and Target</string>
</root>
A reference to the new strings file must be included in the extension.xml file:
Code:
  <base>
    <includefile source="./strings/strings_5e.xml" />
   . . .
As mentioned above, from a prior posting, I know the visibility button is defined in the ct_effect <windowclass> in the 5E\ct\ct_host.xml file, so I created a ct subfolder in my extension and then copied the ct_host.xml file into it from the 5E ruleset. The new visibility options were added to the button using <state>:
Code:
  <buttonfield name="isgmonly">
    <bounds>28,1,24,10</bounds>
    <state icon="button_toggle_visible" tooltipres="visibilityon" />
    <state icon="button_toggle_gm" tooltipres="visibilityoff" />
    <state icon="button_toggle_self" tooltipres="effect_tooltip_visibilityself" />
    <state icon="button_toggle_trgt" tooltipres="effect_tooltip_visibilitytrgt" />
  </buttonfield>
I included the new file in my extension.xml file:
Code:
  <base>
    <includefile source="./strings/strings_5e.xml" />
    <includefile source="./ct/ct_host.xml" />    

    <script name="EffectManager5E" file="../../rulesets/5E/scripts/manager_effect.lua" />
    <script name="EffectManager" file="./scripts/manager_effect.lua" />
  </base>
Now to look at how the changes affect the GUI. I saved all my files, reloaded the ruleset, brought up the Combat Tracker, deleted all existing effects, and then clicked the little Add Effect button four times. Note the undesired behavior of the button still exists, the effect’s initial visibility is “VSBL”. It’s moot since it doesn’t show up in the player’s Combat Tracker, but it is still irritating. I’ll surely revisit this in the future! I then cycled the visibility buttons so that each one displayed a different state and added a bit of descriptive text. Here’s a screenshot:
13a -Options.png

I saved the DB to disk using /save in the Chat box. I brought up the campaign’s db.xml file in Notepad++ and searched for <effects>. The <isgmonly> and <label> fields have the desired values: <isgmonly> cycles through the four button states, 0 through 3, and each <label> has the correct corresponding string.
Code:
  <effects>
    <public />
    <id-00002>
      <public />
      <duration type="number">0</duration>
      <init type="number">0</init>
      <isactive type="number">1</isactive>
      <isgmonly type="number">0</isgmonly>
      <label type="string">Visible</label>
    </id-00002>
    <id-00003>
      <public />
      <duration type="number">0</duration>
      <init type="number">0</init>
      <isactive type="number">1</isactive>
      <isgmonly type="number">1</isgmonly>
      <label type="string">GM Only</label>
    </id-00003>
    <id-00004>
      <public />
      <duration type="number">0</duration>
      <init type="number">0</init>
      <isactive type="number">1</isactive>
      <isgmonly type="number">2</isgmonly>
      <label type="string">Self and GM</label>
    </id-00004>
    <id-00005>
      <public />
      <duration type="number">0</duration>
      <init type="number">0</init>
      <isactive type="number">1</isactive>
      <isgmonly type="number">3</isgmonly>
      <label type="string">Target, Self and GM</label>
    </id-00005>
  </effects>
Detour: The order that I defined each <state> was deliberate. VSBL and GM were left as is to be compatible with existing db.xml files and existing lua code. The two new options were added with visibility “restriction” in mind. GM restricts visibility the most. SELF is a little less restrictive, TRGT even less so and VSBL the least restrictive. As one cycles the button from the initial state GM, the visibility cycles to SELF, then TRGT and back around to VSBL.

Next some clean up: rid the extension’s copy of ct_host.xml of some of the duplicate code it contains. Unlike lua script files I can delete some of the XML without detriment. With ct_host.xml open in Notepad++, I opened the “View” menu and selected “Fold All”, then clicked the little “+” next to <root>. I deleted all code except for the <windowclass> named “ct_effect” since it contains the modified button.

Having read parts of the Ruleset Modification Guide, I recalled references to various forms of “merge”, in the Templates section. After rereading that section I still didn’t have a very good handle on using merge so I went looking in the forums for examples. This recent thread looked very pertinent. I experimented with some of the merge attribute options mentioned but without success. So I searched for more examples of “merge” in the rulesets using Notepad++. The use of “delete” in the 5E\campaign\record_char_inventory.xml file was inspiring, use delete to remove a control then redefine it. Using the knowledge gained I reduced the extension’s ct_host.xml file to this:
Code:
<?xml version="1.0" encoding="iso-8859-1"?>

<root>
  <windowclass name="ct_effect" merge="join">
    <sheetdata>
      <buttonfield name="isgmonly" merge="delete" />
      <buttonfield name="isgmonly">
        <bounds>28,1,24,10</bounds>
        <state icon="button_toggle_visible" tooltipres="visibilityon" />
        <state icon="button_toggle_gm" tooltipres="visibilityoff" />
        <state icon="button_toggle_self" tooltipres="effect_tooltip_visibilityself" />
        <state icon="button_toggle_trgt" tooltipres="effect_tooltip_visibilitytrgt" />
      </buttonfield>
    </sheetdata>
  </windowclass>
</root>
The new options work fine in the GUI, but lack the lua that implements useful functionality. It looks to be big work, I’ll start gearing up.

Until next time keep on role playing.

Submit "A Neophyte Tackles the FG Extension - Visibility, More Options Please" to Digg Submit "A Neophyte Tackles the FG Extension - Visibility, More Options Please" to del.icio.us Submit "A Neophyte Tackles the FG Extension - Visibility, More Options Please" to StumbleUpon Submit "A Neophyte Tackles the FG Extension - Visibility, More Options Please" to Google Submit "A Neophyte Tackles the FG Extension - Visibility, More Options Please" to Facebook Submit "A Neophyte Tackles the FG Extension - Visibility, More Options Please" to Twitter

Updated June 22nd, 2016 at 06:30 by Minty23185Fresh

Categories
Uncategorized

Comments

  1. damned's Avatar
    Baby steps! Well done. The LUA is a whole other beast!
  2. Minty23185Fresh's Avatar
    Thanks for the comment, damned.
    I have started looking at the lua for this; it looks daunting. Lots and lots of code to touch.
    I'm a bit gun shy after my prior blog post. I have to remedy the problem with that code first.
  3. damned's Avatar
    Ill be honest - if you are not a programer the LUA in this might be too tough. It would be too tough for me - Im no programmer - Im a hack!
    Definitely give it a go though - keeps the brain alive and healthy
FG Spreadshirt Swag

Log in

Log in