Recent Blogs Posts

Setting Default Visibilities for Conditional Effects (e.g. Prone)

This is one in a series of Combat Tracker EVOE blog posts. The series index can be found here.

As with nearly every preceding blog post I start out contrasting FG with and without EVOE. Why break tradition? A portion of the GM’s Effect Manager Utility and Combat Tracker are shown in each of the two panels in the first screenshot.. The upper panel displays information without using EVOE, the lower panel ...

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