Rico's PF2e Framework - preview 2

Show off your RPG maps, campaigns, and tokens. Share your gaming experiences and stories under General Discussion and save this forum for things you've created that may help others run their own games. Use the subforums when appropriate.

Moderators: dorpond, trevor, Azhrei, Gamerdude

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Rico's PF2e Framework - preview 2

Post by RicoTheBold »

Updated to beta 0 preview 2 as of 2020-02-02
Last used with Maptool 1.5.10; has not been tested with 1.5.12, which includes updated JSON parsing, but will probably be fine.


So...this is a second preview version. It's mostly cleaned up - I put some OGL text in there since there's some rules text that was included for the condition report macro and the critical hit/fumble card macros, which weren't in Preview 1. There's not really anything deliberately broken, but still incomplete, so I'm calling it beta 0 preview 2.

All the "basic" functionality I described should be 100% intact, as well as the fancier stuff to the extent that it exists. I ripped out the Bag of Tricks map from my campaign, so...it *might* have broken something, but I don't think any macros included in this file reference that library.

Also, the Doors library includes a few macros that are *slightly* adapted from an old campaign file of Jamz's, but they should still be compatible, up to and including keeping his name for the token properties.
RicoPF2eFramework beta 0 preview 2.cmpgn
(8.47 MiB) Downloaded 127 times


My main warning/caveat will be that I'd expect various data changes (like token properties or JSON data) as I keep trying to figure out the best ways to approach certain problems. But the good news is that if you have any ideas on making some of them different or better, it's early enough that we can just, y'know, do that.

It's not going to compete in any beauty contests right now (although the conditions at least all have a consistent art feel due to my heavy use of game-icons.net content). It's functional, but heavily built on the basic maptool input/output options, not HTML/markdown/CSS/frames. I cannot stress enough that I am not a developer or website guy or anything else relevant beyond the general scripting-level skillset.

I'm definitely open to feedback and even direction/help on how things could be done better. I'd love for some of the philosophical goals to survive (hack-friendly for when you just need to change or add one small thing for your group, automation that doesn't explode with errors when you haven't done the like 10 things that the framework author expected you to have set up but all you want to do is use the HP tracking) even if people more talented than I build something more robust.

Below is an overview of where things sit now as of Beta 0 Preview 2.
Some Design Goals and thoughts about the approaches taken:
* GM can run basically everything
- As the GM, I basically run everything here. A few macros are in place for players to help designate when they raise a shield or rage or whatever, but that's it.
- The macros are mostly all on the GM panel for this reason, but if you want to put them in your players' hands they will generally work fine.
* Hackable
- I want this to be somethwing that is relatively easy for someone familiar with Maptool to modify as they need it.
- This means that calculated values that would show up on a character sheet are generally stored as simple properties.
- Conditions and items and whatnot aren't going to be buried in complex tables with reference indexes that require lookups stored in global properties, etc. I use a few tables, but they're for obvious things like drawing cards.
- At some point, as the datatypes get a little settled, they should be pretty easily documented
* Automation that doesn't implode if you haven't spent a bunch of time configuring something
- I want to always be able to quickly throw a token in and just use it - including it in initiative, tracking HP, adding conditions, whatever. The fancy auto-calculation features should "fail open" and allow me to just set a value whenever it matters (like providing the bonus when rolling initiative).
* Focus on the things that are hard to keep track of
- PF2 is a really GM and player-friendly syste compared to PF1. There's a lot less to worry about, so this framework embraces that and literally wouldn't exist if that weren't the case because I wouldn't have even considered trying to take it on.
- It's much harder for me to remember what everybody's perception bonus is from session to session or monster to player than it is to keep track of how many actions have been used in a given turn.
- Visual representations are a huge benefit for both players and GM - being able to see whether a monster is hurt or not, frightened, whatever, offers a bunch of extra strategy.
* Don't fall into the trap of trying to be a full character creation/validation tool
- This ties into the automation point. I want this to work with homebrew monsters, feats, whatever. Maybe the GM wants to give everyone a free archetype. Cool. I won't stope you.
- Programming in every option that ever gets printed is the kind of tedium I have no interest in doing.
* PCs aren't NPCs
- Maptool's definitions of PCs and NPCs aside, PF2 doesn't handle these the same way.
- PCs are the "PF2e" token type, with levels and proficiencies used to calculate everything
- NPCs are mostly the "PF2eStatblock" token type - values are specifically set, not calculated (unless modified by a condition or something). Bestiary statblocks, adventure NPCs, etc. don't need to be built like PCs in this system, so there's a separate token type just for that.
- "Basic" tokens are basically there to be as simple as possible and require little to no preconfiguration. They're good for HP and dying tracking, as well as conditions. You don't even *have* to do that, but it's nice to have.
Things I have working right now specific to Pathfinder 2:
* State Overlays
- All PF2 conditions as visual state icons, with some extra things that aren't formally conditions but are nice to track (like medicine immunity or a stance), and a macro that runs a report of all the conditions on a token and the rules text (from a table lookup).
- Conditions that modify skills/saves/AC will numerically alter tokens' values
- Dying/Wounded (displayed as images, handled as bars)
- Elevation states, in increments of 5, for changed elevations (a little cumbersome, and noisy, so I'll tweak this eventually) with cosmetic indicators for different types of movement (not currently integrated with the other movement conditions) - basically ripped straight from Jamz's NERPS framework with some slight art tweaks and PF2 movement types
* Conditions with numerical levels (Other than Dying/Wounded, which are detailed later)
- I've added multiple versions for different levels. They also use values stored on the token for calculations (see later discussion). I wish they were easier to tell apart when zoomed out, but I haven't found a better solution I like here. A relatively new addition that was added specifically to support calculations, which generally work.
- Note that on the GM Panel, there are two buttons for each of these - the red speckled button brings the menu to apply different levels, the black button is a cosmetic overlay (equivalent to the level 1 condition) only. Right now these macros only support conditions to level 4 which is *almost* always sufficient. I've added a "[condition] 5+" level" state but not actually implemented it in the macros.
* PF2 lighting rules (all set with grids)
- Distinct light colors for bright/dim lights
- Light sources from the core rule book and bestiary
- Darkness at the typical 1st and 4th (heightened) levels
- A bunch of "light", "like a torch", and "Darkness" at every spell level for counteracting purposes if people heighten spells to weird levels
- Generic colored auras of many sizes for determining if things are within range of emanations (didn't tie to specific spells so you can just pick a color and range; I use it to see if people are in range of bard compositions for instance)
* Initiative rolls
- Prompts for initiative for selected tokens, presented all on one pane, broken down into:
- Results from PC tokens (my players like to roll their own)
- bonuses for NPCs (once per token image, so it will only ask once for copies of tokens).
- Can use configured values as bonuses for NPCs, with options to use literally any skill if desired (but presets for perception and stealth)
- It takes the bonuses and rolls for NPCs uniquely, so the different copies of tokens will not all have the same initiative
* A "Next Initiative" macro
- Provides warning for upcoming turns
- Clears specific "action" states, like raised shields, cover, delay, or readied action/used reactions
- Calls for dying tests for dying NPCs
- Removes dead tokens from initiative
* Health, wounds, dying, etc.
- HP Bars
- I have HP bars that display HP/tempHP without taking up very much space, which I use for NPCs and PCs alike (I tend not to describe the health of monsters throughout battles, so I don't mind sharing it for NPCs). Because it's a "shared" bar approach, built from the tutorial on the fading arc bar, it doesn't play perfectly with "chunked" incremental HP settings.
- They could easily be swapped for other art assets, including the fading arc bar.
- I spent a few hours last week checking the colors in a color-blind testing website, and the green and red are basically identical for one kind of color blindness. Included is alternate colors in the same style (just swapping green to blue works great there with everything else, but I made a bunch of other ones when I was designing them if someone wants to use them for a different framework). You just have to rename the bars to swap it out.
- They actually have a bar designated for nonlethal as a different type of damage ('cause of the tutorial I was following back when using the playtest rules) but it's not needed in PF2 so I might remove it.
- One HP Δ macro, that does a bunch of stuff:
- Lets you enter a number of HP, then select lethal/nonlethal damage, healing, or adding temporary HP.
- Asks if the character is taking damage from a critical hit
- Reports the current HP value, if it's set, or allows you to change it on the spot
- Reports the current Temporary HP value, if it's set, or allows you to change it on the spot
- Reports the current Maximum HP value, if it's set, or allows you to change it on the spot
- It then takes those values and appropriately modifies the token, setting dying/wounded values according to the rules if the token is brought to 0 or healed from dying, or ignoring new temporary HP values that are less than the amount a token already has, etc.
- It also moves initiative for anything that's knocked out to just before the current turn (initative uses levels of precision to ensure this works - it's kind of ugly to see the values but the way the initative macros work this seemed the most reliable way)
- One Wounds/Dying Δ macro, which lets you directly set the current wounded/dying values, or the DyingMax value
- DyingMax is for stuff that should die at some value other than Dying 4 (e.g., set to 1 if you want to have something like undead/constructs or really unimportant monsters that should die instantly, set to 5 if it's a PC with Diehard)
- A Basic token config macro (formerly called Set HP) that allows for bulk setting of HPMax and DyingMax values to lazily configure tokens quickly (allows you to set a bunch of token copies at once) - it could stand to be updated to prompt if you have mixed tokens selected rather than just error out
- A consistent HP bar/dying tracker update macro, which updates the display and will automatically kill things that should be dead
- Now actually takes into consideration if a token is Doomed, with a slight hack so that if you set things to die at Dying 1 anyway (i.e., unimportant things or undead/constructs), being Doomed doesn't kill them
- Will also un-kill things that aren't dead if you screwed up and went back with the wounds/dying macro to fix it by reducing the dying values
- A dying test macro, so NPCs can bleed out while players are discussing whether or not to stabilize them (also invoked automatically for NPCs by the next initiative macro, so they can bleed out mid-fight without slowing the game down)
- It makes it pretty easy to let unimportant NPCs go through the full dying rules, which probably leads to more NPCs captured alive for interrogation

* Critical Hit and Critical Failure decks
- Paizo's 2nd edition cards manually transcribed and set into random tables with simple macros to provide output
- Probably needs a pass to make sure it's compliant with the OGL license these use, so I'll leave the tables out until I've done that (I don't *think* there are any of the "Product Identity" proper nouns in the card text, but I haven't specifically checked)
- Also I guess I'll have to add the OGL text in the framework somewhere...joy
- And FYI, these add a lot of volatility - I tie them to the hero point mechanics for players to offset the "why do martials critically fail on natural ones but spells with saves can never hurt the caster because they don't make an attack roll?" problem
Things that I'm working on now:
* More complex character tracking with two new token types
- One for PCs or NPCs built from classes using the PC rules (calculating skills, HP, and whatnot through level and proficiency). Basically like my calculating PDFs, they provide an easy-to-update reference sheet that could interact with calculations in the future.
- One for NPCs built as statblocks (just enter the values from the statblock).
- Most variable/optional stuff is stored as JSON arrays full of JSON objects - each skill or save is an object in an appropriate array. Calculated totals (basically the final numbers you'd write on a physical character sheet for reference) are stored as generic properties, because it's more hack-friendly for users, and makes it easier to write macros that support the 3 token types (PC/class+levels, Statblock, and Basic token that probably just has HP). It turns out getting null pointers from JSON commands is lame.
- Buffs/debuffs from conditions. This...actually works right now, basically. Adding the condition adds a JSON object that can be referenced for calculations, and my first attempt worked pretty nicely. The biggest issue here is that the set of "scopes" doesn't scale well - it's easy to make a condition that affects all checks using the Strength modifier, but much harder to apply a penalty to just melee bludgeoning and slashing weapons. I'm not sure how other frameworks do it, so...super open to feedback here from people who have this whole data architecture thing down.
- Spellcasting is currently just adding in some proficiency for calculation.

* Character sheets (or at least usable pop-up statsheets)
- I'm way less familiar with setting up good character sheets (or frames/HTML/CSS generally). The things like the condition report were a bit of learning about how Maptool handles frames/tables/formatted outputs, but it's something that feels like it needs more planning than I've really done on how the character info all fits together.
- In lieu of that, I have easily-accessed properties, with display versions that pop-up on hover. So, useful for quick reference on what a token's will save is, including (but not showing) the conditions modifying it.

* Group/Secret checks
- I have been using the secret check rules, and I've been rolling them manually. It's cumbersome to roll a bunch of perception or recall knowledge checks at once. This was a lot of the impetus to add these other details to the character sheets.
- Output is super ugly right now. I'm thinking of making this a nice frame or something. Might wait until the HTML5 support.
Things that I haven't really taken on but would kind of like:
* Tracking spells prepared/used/spell slots
- I have a player who's not always available, and so half the time I'm running his character and have no idea how many spells he cast last session
* Weapons/Attacks
- Generally I'm thinking something like my other approaches, i.e., an array of JSON objects in a predictable place and calculated/set properties (depending on token types) that reference them, but I've been focused on the things that literally every PC/NPC has, like skills and saves.
- Automated attack and damage rolls - I don't know how often I'd use them, but for big combats they'd likely make things faster.
* Afflictions
- Some automated affliction rolls would be nice - poisons and diseases can get into a lot of rolls if PCs decide to use them a bunch, but it otherwise doesn't come up that much.
* Timers for stuff (by round)
- Probably needed for afflictions
- Would be nice for states, too
* Resistances or immunities for damage calculations
- Way down the line. By the time this matters much you're probably already automatically applying damage from automated attack/damage rolls.
* Real character sheets
- Might wait for HTML5 since that just hit alpha, and/or solicit help here from someone who knows what they're doing and can get it functional faster with better consideration of future functionality
I also have liberally borrowed/stolen from other folks' work as I learned, and there's some stuff I use essentially untouched
* Wolph42's Bag of Tricks (not included in the framework)
* Some specific macros/approaches from JamzTheMan's old NERPS campaign file from pre-1.5 taught me a lot of stuff, and I like his simple method for doors, so I use that (but created a couple simple macros to open/close all doors on a map at once or to open/close a selected door instead of requiring a different token to be there)
* These things are usually on their own Lib tokens, because they're not PF2-specific, so you can take them or leave them. In the BoT case, it's really just the normal BoT and one separate token where I edited the handout macro because I got tired of changing the size every time. The other slight changes I made recently were actually merged into the newest version.
* I was also inspired by that french Savage Worlds framework, which I tweaked for my own Savage Worlds campaign a few years ago. It's a good reminder that just tracking the very basics - alive/dead, how close to alive/dead - is already really useful. For a long time my PF2 playtest framework was entirely cosmetic. Then...HP and initiative. Or Initiative and HP, don't remember the order. I still use the Dead/Out art from this framework, because it's beautiful and distinct.
One other oddball thing that's not PF2 but works nicely with it
For tracking time (including 10 minute durations and 1 hour durations) and adding some consequences to sitting around and repeatedly using Treat Wounds in a dungeon, I've adapted a time/tension pool system, found here: https://theangrygm.com/tension-on-the-road/

Basically, I just implemented it (mechanically) exactly as described by that dude, but with 3 separate pools - one for 10 minute durations (if 6 go by, that's an hour and durations expire), one for chunks of a day (as described in that post, but I don't really use it), and one for within an encounter (I've only used it once). The per-hour one I think just works really well with PF2 effect durations, and adds some sense of urgency while exploring a hostile dungeon or cave or whatever.

It's simple, clean (adds a little frame so everyone can see and highlights the last-used pool), and easy to use. It's also entirely modular, on its own Lib token and everything.
Pathfinder Compatible Community Use license info
This campaign framework uses trademarks and/or copyrights owned by Paizo Inc., which are used under Paizo's Community Use Policy. We are expressly prohibited from charging you to use or access this content. This campaign framework is not published, endorsed, or specifically approved by Paizo Inc. For more information about Paizo's Community Use Policy, please visit paizo.com/communityuse. For more information about Paizo Inc. and Paizo products, please visit paizo.com.

OPEN GAME LICENSE Version 1.0a
The following text is the property of Wizards of the Coast, Inc. and is Copyright 2000 Wizards of the Coast, Inc ("Wizards"). All Rights Reserved.

1. Definitions: (a)"Contributors" means the copyright and/or trademark owners who have contributed Open Game Content; (b)"Derivative Material" means copyrighted material including derivative works and translations (including into other computer languages), potation, modification, correction, addition, extension, upgrade, improvement, compilation, abridgment or other form in which an existing work may be recast, transformed or adapted; (c) "Distribute" means to reproduce, license, rent, lease, sell, broadcast, publicly display, transmit or otherwise distribute; (d)"Open Game Content" means the game mechanic and includes the methods, procedures, processes and routines to the extent such content does not embody the Product Identity and is an enhancement over the prior art and any additional content clearly identified as Open Game Content by the Contributor, and means any work covered by this License, including translations and derivative works under copyright law, but specifically excludes Product Identity. (e) "Product Identity" means product and product line names, logos and identifying marks including trade dress; artifacts; creatures characters; stories, storylines, plots, thematic elements, dialogue, incidents, language, artwork, symbols, designs, depictions, likenesses, formats, poses, concepts, themes and graphic, photographic and other visual or audio representations; names and descriptions of characters, spells, enchantments, personalities, teams, personas, likenesses and special abilities; places, locations, environments, creatures, equipment, magical or supernatural abilities or effects, logos, symbols, or graphic designs; and any other trademark or registered trademark clearly identified as Product identity by the owner of the Product Identity, and which specifically excludes the Open Game Content; (f) "Trademark" means the logos, names, mark, sign, motto, designs that are used by a Contributor to identify itself or its products or the associated products contributed to the Open Game License by the Contributor (g) "Use", "Used" or "Using" means to use, Distribute, copy, edit, format, modify, translate and otherwise create Derivative Material of Open Game Content. (h) "You" or "Your" means the licensee in terms of this agreement.

2. The License: This License applies to any Open Game Content that contains a notice indicating that the Open Game Content may only be Used under and in terms of this License. You must affix such a notice to any Open Game Content that you Use. No terms may be added to or subtracted from this License except as described by the License itself. No other terms or conditions may be applied to any Open Game Content distributed using this License.

3. Offer and Acceptance: By Using the Open Game Content You indicate Your acceptance of the terms of this License.

4. Grant and Consideration: In consideration for agreeing to use this License, the Contributors grant You a perpetual, worldwide, royalty-free, non-exclusive license with the exact terms of this License to Use, the Open Game Content.

5. Representation of Authority to Contribute: If You are contributing original material as Open Game Content, You represent that Your Contributions are Your original creation and/or You have sufficient rights to grant the rights conveyed by this License.

6. Notice of License Copyright: You must update the COPYRIGHT NOTICE portion of this License to include the exact text of the COPYRIGHT NOTICE of any Open Game Content You are copying, modifying or distributing, and You must add the title, the copyright date, and the copyright holder's name to the COPYRIGHT NOTICE of any original Open Game Content you Distribute.

7. Use of Product Identity: You agree not to Use any Product Identity, including as an indication as to compatibility, except as expressly licensed in another, independent Agreement with the owner of each element of that Product Identity. You agree not to indicate compatibility or co-adaptability with any Trademark or Registered Trademark in conjunction with a work containing Open Game Content except as expressly licensed in another, independent Agreement with the owner of such Trademark or Registered Trademark. The use of any Product Identity in Open Game Content does not constitute a challenge to the ownership of that Product Identity. The owner of any Product Identity used in Open Game Content shall retain all rights, title and interest in and to that Product Identity.

8. Identification: If you distribute Open Game Content You must clearly indicate which portions of the work that you are distributing are Open Game Content.

9. Updating the License: Wizards or its designated Agents may publish updated versions of this License. You may use any authorized version of this License to copy, modify and distribute any Open Game Content originally distributed under any version of this License.

10. Copy of this License: You MUST include a copy of this License with every copy of the Open Game Content You Distribute.

11. Use of Contributor Credits: You may not market or advertise the Open Game Content using the name of any Contributor unless You have written permission from the Contributor to do so.

12. Inability to Comply: If it is impossible for You to comply with any of the terms of this License with respect to some or all of the Open Game Content due to statute, judicial order, or governmental regulation then You may not Use any Open Game Material so affected.

13. Termination: This License will terminate automatically if You fail to comply with all terms herein and fail to cure such breach within 30 days of becoming aware of the breach. All sublicenses shall survive the termination of this License.

14. Reformation: If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable.

15. COPYRIGHT NOTICE
Open Game License v 1.0 Copyright 2000, Wizards of the Coast, Inc.
System Reference Document. Copyright 2000. Wizards of the Coast, Inc; Authors: Jonathan Tweet, Monte Cook, Skip Williams, based on material by E. Gary Gygax and Dave Arneson.

Core Rulebook
Pathfinder Core Rulebook (Second Edition) © 2019, Paizo Inc.; Designers: Logan Bonner, Jason Bulmahn, Stephen Radney-MacFarland, and Mark Seifter.

Bestiary
Daemon, Guardian from the Tome of Horrors Complete © 2011, Necromancer Games, Inc., published and distributed by Frog God Games; Author: Scott Greene, based on original material by Ian McDowall.
Dark Creeper from the Tome of Horrors Complete © 2011, Necromancer Games, Inc., published and distributed by Frog God Games; Author: Scott Greene, based on original material by Rik Shepard.
Dark Stalker from the Tome of Horrors Complete © 2011, Necromancer Games, Inc., published and distributed by Frog God Games; Author: Scott Greene, based on original material by Simon Muth.
Dragon, Faerie from the Tome of Horrors Complete © 2011, Necromancer Games, Inc., published and distributed by Frog God Games; Author: Scott Greene, based on original material by Brian Jaeger and Gary Gygax.
Genie, Marid from the Tome of Horrors Complete © 2011, Necromancer Games, Inc., published and distributed by Frog God Games; Author: Scott Greene, based on original material by Gary Gygax.
Mite from the Tome of Horrors Complete © 2011, Necromancer Games, Inc., published and distributed by Frog God Games; Author: Scott Greene, based on original material by Ian Livingstone and Mark Barnes.
Pathfinder Bestiary (Second Edition) © 2019, Paizo Inc.; Authors: Alexander Augunas, Logan Bonner, Jason Bulmahn, John Compton, Paris Crenshaw, Adam Daigle, Eleanor Ferron, Leo Glass, Thurston Hillman, James Jacobs, Jason Keeley, Lyz Liddell, Ron Lundeen, Robert G. McCreary, Tim Nightengale, Stephen Radney-MacFarland, Alex Riggs, David N. Ross, Michael Sayre, Mark Seifter, Chris S. Sims, Jeffrey Swank, Jason Tondro, Tonya Woldridge, and Linda Zayas-Palmer.

Pathfinder Critical Hit Deck (Second Edition) © 2019, Paizo Inc.; Author: Stephen Radney-MacFarland

Pathfinder Critical Fumble Deck (Second Edition) © 2019, Paizo Inc.; Author: Stephen Radney-MacFarland
Last edited by RicoTheBold on Sun Feb 02, 2020 7:32 pm, edited 12 times in total.

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

This was a post on the Maptool Discord server - haven't verified it's still current, but left because it explains how the JSON was set up for armor and whatnot.
I'm super happy to collaborate on any of these. I think there's a lot that I have that works pretty well, but I don't have anything like timers in play at all (other than some stuff my "next initiative" macro does). I will say that I have separate libraries for a bunch of these things because I find it super confusing when there are like 300 macros on a library, and by separating them they can be a bit more modular - but there are some interdependencies that exist and aren't mapped (like adding the drained condition macro from Lib:States modifies HP, so it calls the changeHealth macro from Lib:Health).
I have conditional bonuses/penalties working, but the recalculation is pretttttty slow (about 1-2 seconds), and doing it every time one of those conditions changes is maybe overkill.

I also got sidetracked futzing with some art stuff - I ended up adding in some frames for displaying the relative threat something represented (I have both big/fancy versions and smaller/simple versions).

This week is pretty much the worst possible week for me to to try to work on anything because I'm both coming back from holiday and wrapping up a project that's due early next week.

One thing I'll say about my approach re: properties vs. JSON.

I try to use properties for numbers used for proficiency-based checks.

I.e., if it's a total roll modifier or HP/AC/whatever on a character sheet, that part is probably a property.

The idea is that it's the easiest way to reference in the most flexible ways, and supports multiple approaches (*PF2e* tokens are for tokens built from classes like PCs, with caclulations based on level and whatnot; *PF2eStatblock* are for tokens with final values entered directly as statblocks like monsters or Adventure Path NPCs; *Basic* tokens are just HP/dying/wounded and cosmetic conditions (and Doomed). You can mix and match these however you want, and both the non-Basic types will support subsequent calculations, like conditions.

For anything used for those calculations, I'm almost certainly using an array of JSON objects (stored in a property).

So every armor type is a JSON object, which can track the modifiers. Every skill is a JSON object, so that you can have variable numbers of/names of Lore skills. I expect weapons/attacks will be that way, too. Perception is built that way, but not really used (I imagine having different versions for different types of detection ... i.e. visual, auditory, tremorsense, etc.). Saves are JSON objects.

Conditional bonuses/penalties are JSON objects that capture the actual typed/untyped bonuses/penalties and the different scopes they apply to - so like, if you're unconscious and flat-footed, you can select both of those and (after a 1-2 second recalc) they'll apply to the checks based on the configured scopes, and the redundancies won't stack. The way I designed it allows for the matched scope to be pretty flexible - either one string, "any of" arrays of strings, "all of" arrays, or "at least one of array 1 & 2 (& 3)."

The goal with the scope-check approach was to support ridiculously things like Swimming giving a penalty to melee slashing/bludgeoning attacks. This is just some future-proofing, I don't have attacks modeled at all. The upside of flexibility has the downside of needing to compare scopes against everything with a check that could be relevant, which includes a bunch of recalculations. I mitigate it somewhat with some separate calculations (i.e., Drained will recalculate your max HP and saves, but not your skills since there aren't any that are based on your Con modifier). It does mean each modifier needs some level of "new macro" which I don't love, but can be rearchitected in the future.

I'm also trying really hard to make it easily "hackable." There aren't properties with a thousand predefined table indexes that you have to look up and edit five different places to get it to work. If you made a homebrew spell that modifies some calculations, you should be able to just add the JSON object to the conditional modifiers array and have it work. For my armor objects, I put the predefined ones in a macro that's super simple to edit, so you can add a new one without needing look in twelve different places, or you can create a custom one using a different macro that just asks you for the parameters and adds it to your token. If the predefined armors macro gets updated, then all you need is that updated library and you're good to go. (Tables are used for a few things that shouldn't need frequent modifications.) Basically - I'm trying to make it so people can be all, "Hey, I saw you didn't have this so I added this thing" and it can just be ignored or incorporated without a big thing.
Last edited by RicoTheBold on Sun Feb 02, 2020 7:26 pm, edited 2 times in total.

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

This was a post on the Maptool Discord server - it goes into a little more detail on the different token types.
Any tokens in Maptool can obviously be set as PCs or NPCs, regardless of their type or system, so I'll address this bit later.

Most of your question is probably about how the tokens are treated from a data and configuration perspective. For that, there are currently three relevant token types in the framework: Basic, PF2e, and PF2eStatblock.

Basic tokens can take HP/damage/temp HP, track dying/wounded states automatically, and have cosmetic conditions applied. They're what I've been using to run games since the PF2 playtest. If you need to quickly throw a token into a fight without preconfiguring it, this will work.

PF2e tokens are for entities built like PCs on a paper character sheet. So you configure their level, their proficiencies, add their ability modifiers, what kind of armor, item bonuses, and then things are calculated.

PF2eStatblock tokens are built like NPCs taken from an adventure path or Bestiary statblock. You just enter the final stats and move on. Set the HP, set the total skill bonuses, their saves, etc.

I'm trying to make sure that everything that needs to calculate from any of this stuff will work the same way after the tokens are created - for instance, if you want to roll initiative using stealth or perception, the macro doesn't care whether it was pre-calculated as a PF2e token or set arbitrarily as a PF2eStatblock token.

Conditions, similarly, should be able to modify the final numbers the same across those tokens (but it's a little slow).

Rolls requested from basic tokens (initiative for example) will pretty much just prompt you to enter the result (or relevant check modifier), so they're still usable.
There are a few places where I treat tokens set as PCs differently from tokens set as NPCs - my initiative macro always prompts for the results of a PC's roll because my players want to roll their own initiative, but it will ask for the modifiers for NPCs that are basic tokens or which skill/perception to use for the check if they're a PF2e/PF2eStatblock token. Dying checks, similarly, are automatically done for NPCs when they come up in initiative but not for tokens set as PCs (regardless of token property type - and this works with Basic tokens just fine).
Last edited by RicoTheBold on Sun Feb 02, 2020 7:26 pm, edited 1 time in total.

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

Placeholder for future information

SDShannonS
Giant
Posts: 242
Joined: Tue Sep 12, 2006 12:21 am
Location: San Diego, CA, US

Re: Rico's PF2e Framework - preview

Post by SDShannonS »

Dear Mr. TheBold,

I downloaded your framework from the above link and I must say that I am both impressed and disappointed. In reviewing the Lib: tokens, I can see you have put a ton of work into creating a number of elements that put the framework much further along than I had thought it was. However, other than a small handful of State-toggle macros, there seem to be no campaign macros that call any of the functions on the Lib: tokens so the only way to activate those macros (that I was able to discover) was by selecting the Lib: token itself and then using the Selected frame. But I daresay few people are going to want to add the Lib: token to their initiative, for example, so I'm not clear on how you intend one to use those macros on the actual PC or NPC tokens.

Can you clarify how the framework is to be used in its current state?
"You must be the change you wish to see in the world."
- Mahatma Gandhi

"You know what the chain of command is? It's the chain I go get and beat you with until you understand who's in ruttin' command here."
- Jayne

RicoTheBold
Kobold
Posts: 21
Joined: Sun Sep 13, 2009 12:52 am

Re: Rico's PF2e Framework - preview

Post by RicoTheBold »

I've been super busy with work (and some health issues), but have made somewhat more progress and fixed a bunch of bugs that popped up during the transition to lib-called macros. These changes are only in my ongoing campaign file, so I'll do another export/cleanup effort as soon as I can, hopefully tomorrow (edit: Yup, see updated version of 1st post). I'd suspend any further experimentation until then, because I haven't tracked those bugs specifically, just fixed them as I found them - even mid-session in a few cases.

But your question calls a much broader complaint, and this, I suspect, mostly comes from lack of documentation. The short answer is that nearly all macros are on the GM panel, not the campaign panel. Click on that and you'll find the relevant macro buttons you're missing. I do pretty much all the running of things during the game, so my players can mostly just move tokens around and do specific actions with visual indicators like raising shields or going into stances or raging.

I'm used to managing everything - I used to use Hero Lab with PF1 to manage initiative and all the monsters anyway, and before digital tools I largely did it on paper. The only big difference for me now is that I also track player HP, and increasingly will have the ability to track their other statistics (just this last session I corrected one player's self-reported AC as it did not match the token's calculated AC and he had overlooked the Clumsy condition).

SDShannonS
Giant
Posts: 242
Joined: Tue Sep 12, 2006 12:21 am
Location: San Diego, CA, US

Re: Rico's PF2e Framework - preview 2

Post by SDShannonS »

Thanks for the reply. I’ll check that out and see where we stand.
"You must be the change you wish to see in the world."
- Mahatma Gandhi

"You know what the chain of command is? It's the chain I go get and beat you with until you understand who's in ruttin' command here."
- Jayne

Elorebaen
Dragon
Posts: 365
Joined: Sat Dec 22, 2007 5:37 pm

Re: Rico's PF2e Framework - preview 2

Post by Elorebaen »

Thanks again for sharing Rico! I am going to download and try out this weekend.

User avatar
Micco
Giant
Posts: 148
Joined: Mon Jun 16, 2008 10:21 pm

Re: Rico's PF2e Framework - preview 2

Post by Micco »

Thanks a bunch for this Rico! I just wanted to drop in to tell you that my group has come back to MapTool now that we have to play remotely. Your PF2e Framework is making it a much better experience than we were expecting, so I just wanted to say thanks and provide some positive feedback.

Post Reply

Return to “User Creations”