Recent Blogs Posts

In a previous post I detailed how I reduced duplicated lua script in my fledgling extension. Play testing the extension revealed a design error. The issue: Windows cannot resolve a folder path into a ruleset .pak file. (For background information, the reader might consider reviewing the prior post and in particular the first few comments attached to it.)

An obvious remedy for the problem is to insert .pak into the path as it is specified in the extension.xml file. I had doubts, but ...

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 ...

This time I’ll look at reducing the size of the manager_effect.lua file in my extension. Recall from last time, I copied that lua file, in its entirety, to my extension then added a single line of code to change the default behavior of an effect’s initial visibility. Having nearly 1500 lines of duplicate code troubles me.

Detour: Why is duplicating code bad practice? For one it bloats the size of your program, and for certain languages that can cause decreased execution speed. ...

Due to posting limits, I have had to split this session into three posts.
This is part 3 of 3.

(continued from part 2)

To test the extension, I deleted all the effects that were applied to the Orc, saved all my edited files, and reloaded the ruleset. Once FG was up I started a second instance of FG and joined the campaign. In the second instance I loaded Zacchaeus’s 20th level Paladin and brought up the Combat Tracker. Then I started a third instance of ...

Due to posting limits, I have had to split this session into three posts.
This is part 2 of 3.

(continued from part 1)

Now to decipher the statement in line 535 (FG v3.1.7). The statement starts with “DB.setValue”. From previous work for this blog series I know DB refers to the DB Package and setValue( ) is a function in that Package described in the XML and Scripting Reference. From the document I see that this statement writes data using the parameters ...