New Snippet: Calculated Fields

[Silveras]

Right.. the broader the scope, the more likely there is to also be a resource issue.. a matter of slowing the application while it searches for applicable snippets in applicable topics.

In addition, there is also the need for greater complexity in the search criteria. A calculated snippet that operates on all values of a certain target snippet may still require additional parameters.. otherwise, the calculated snippet may operate on too broad a range. Using the example above, a snippet of "gold" on Community Topics... it is highly unlikely to be desired that it total all gold for all Communities in all countries of the game world. So there would need to be some way to filter the Topics across which it operates.

Even the "relative date" snippets I mentioned could require additional limitations. Probably, the "relative date" snippets would need to limit their updates to when the Topic they are on is re-visited (much like how existing links recognize that their linked topic has changed, and prompts to change the text to match). Yet that could mean that the Timeline display shows inaccurate information for Topics that are not visited often. The alternative.. that changing the "anchor date" triggers an update of all related "relative dates" is possible, but then it becomes necessary to consider whether it is necessary to limit the number of such "anchor dates" and/or "relative dates"'; otherwise, the application may appear "stuck" while it is applying the changes.

[Cornelius]

Although I find this an interesting idea, I wonder when this option will be used.
As I see it it is mainly used when you input data into an existing realm. the data would only change during the input, not thereafter. Or is there a way you want to use it in other circumstances I do not see at the moment.

If during input is the only moment the data changes it should be possible to fixate it at that moment.

Calculating snippets would create a new sort of relationship. In this case between snippets instead of topics. The program should identify that the relationship changes when one of them is deleted or changed.

[Silveras]

Originally Posted by Cornelius

Although I find this an interesting idea, I wonder when this option will be used.
As I see it it is mainly used when you input data into an existing realm. the data would only change during the input, not thereafter. Or is there a way you want to use it in other circumstances I do not see at the moment.

If during input is the only moment the data changes it should be possible to fixate it at that moment.

Calculating snippets would create a new sort of relationship. In this case between snippets instead of topics. The program should identify that the relationship changes when one of them is deleted or changed.

In the case of the "relative dates", it would come up in the course of using the material to run a campaign.

For example, Rise of the Runelords AP from Paizo.

The dates are left flexible for the GM to decide when the campaign begins. A number of key events are tied to "Five years before". The pace of the adventure is also left dependent upon the group... some aggressive groups will move from part to part faster than others who take more time. But when they are prepared to move on, there are encounters with histories that are based on "1 year ago", "six months ago", "1 week ago", etc. Exactly when those events occurred will be determined by when the players trigger that part of the adventure to begin (although, the longer back it is, the less need for it to be exactly that long ago).

In other cases, a particular part of the adventure may be on a "timer".. the players may have only a fixed amount of time in-game to prevent something bad from occurring. The date/time of the bad outcome is undefined until the date/time of the players' start is determined.

[Cornelius]

Originally Posted by Silveras

In the case of the "relative dates", it would come up in the course of using the material to run a campaign.

For example, Rise of the Runelords AP from Paizo.

The dates are left flexible for the GM to decide when the campaign begins. A number of key events are tied to "Five years before". The pace of the adventure is also left dependent upon the group... some aggressive groups will move from part to part faster than others who take more time. But when they are prepared to move on, there are encounters with histories that are based on "1 year ago", "six months ago", "1 week ago", etc. Exactly when those events occurred will be determined by when the players trigger that part of the adventure to begin (although, the longer back it is, the less need for it to be exactly that long ago).

In other cases, a particular part of the adventure may be on a "timer".. the players may have only a fixed amount of time in-game to prevent something bad from occurring. The date/time of the bad outcome is undefined until the date/time of the players' start is determined.

Interesting ideas. Some comments (not at critizism, but something that sprang to my mind reading this).

That would require some sort of anchor snippet that the GM fixates at a certain moment. Namely the moment (part of) the adventure is started.

The second part requires that you input the time that is used as they proceed through the adventure, in order for the timer to set. This also means that in the plot view suddenly certain paths become closed as the timer has ran out. I am not sure if you can program that into RW at all.

[Silveras]

Originally Posted by Cornelius

Interesting ideas. Some comments (not at critizism, but something that sprang to my mind reading this).

That would require some sort of anchor snippet that the GM fixates at a certain moment. Namely the moment (part of) the adventure is started.

The second part requires that you input the time that is used as they proceed through the adventure, in order for the timer to set. This also means that in the plot view suddenly certain paths become closed as the timer has ran out. I am not sure if you can program that into RW at all.

Oh, I am not advocating any kind of programmatic timer within RealmWorks. The "timer" scenario I was talking about would simply mean that, when the "anchor" date for the start of the time period was set, the end date would be a calculated snippet (+3 days or the like).

The GM should be keeping track of current date and time, to some degree, anyway. It doesn't have to be as precise as "Oh, and you're out of time.. too bad.. the villains win" because the PCs were late by a round or two (except in rare cases for specific encounters).

Really, most Adventure Paths move "at the speed of plot", meaning that any "timer" is not literally a timer in the sense of an hourglass or stopwatch... except that specific encounters may have a requirement that the PCs finish their actions within "X rounds". For the dramatic tension in the campaign, though, the PCs always arrive "just in time" to interfere.

[Silveras]

On a different note.. a case for another calculated snippet occurs to me: Victory Points.

Some adventures/scenarios award the PCs "Victory Points" (or another term) for actions taken during the adventure. Sometimes it is a war situation, with the PCs acting as a small unit within the larger battle -- the degree of the PCs' success determines the degree of overall victory, as measured by the points they accumulate.

In this case, a table-like snippet for entering the awards of points, with the sum calculated, would be useful.

Note that this is, again, a limited-scope type of thing. The data is entered on one Topic in a single complex snippet. This would help to keep performance impact lower.

[Cornelius]

Originally Posted by Silveras

On a different note.. a case for another calculated snippet occurs to me: Victory Points.

Some adventures/scenarios award the PCs "Victory Points" (or another term) for actions taken during the adventure. Sometimes it is a war situation, with the PCs acting as a small unit within the larger battle -- the degree of the PCs' success determines the degree of overall victory, as measured by the points they accumulate.

In this case, a table-like snippet for entering the awards of points, with the sum calculated, would be useful.

Note that this is, again, a limited-scope type of thing. The data is entered on one Topic in a single complex snippet. This would help to keep performance impact lower.

To me this feels as something that is more on the Herolab side of things than on the RW side. Only the end result is something I would enter into Realmworks.

[Silveras]

Originally Posted by Cornelius

To me this feels as something that is more on the Herolab side of things than on the RW side. Only the end result is something I would enter into Realmworks.

I could see that.... IF HeroLab supported "group operations" of some kind. The points I am talking about are not per-character, they are shared as "campaign progress" sorts of things.

I actually have considered suggesting a "The Party" new Hero-type for HeroLab, as a potential way to implement some of the desired improvements to the Tactical Console for Pathfinder without actually touching the Console itself.

[Cornelius]

Originally Posted by Silveras

I could see that.... IF HeroLab supported "group operations" of some kind. The points I am talking about are not per-character, they are shared as "campaign progress" sorts of things.

I actually have considered suggesting a "The Party" new Hero-type for HeroLab, as a potential way to implement some of the desired improvements to the Tactical Console for Pathfinder without actually touching the Console itself.

Ok. I am not that familiar with Herolab myself, as I usually play systems that are not supported by it. I think this option is one of those grey area things. I agree that it is a sort of campaign progress tracker so in that it could be part of RW.