Excellent questions, Deadolus. Let's go through them one by one:
Your Flank Detection (I assume) is to determine if to apply the combat advantage bonus or not? Does your framework take in to account features, like all-round vision, and other features or conditions where tokens (PC or Monster) are not flanked? Does it take in to account other conditions that may cause tokens to be granting combat advantage? If so, what are they?
Yes but unfortunately there is no way for the framework to tell if the victim is susceptible to flanking or not so this situation must be handled manually. If the object token has the "Eyes In The Back Of Your Head" feat for example, you can work around the problem by setting its "Altitude" to 1 or -1. This defeats the framework's flank detection mechanism while still allowing the flanking tokens to reach the object token. Combat advantage is also awarded to the attacker if either of the following applies:
- He is adjacent to the prone target and making a melee attack
- He is invisible
Although all three of these situations do not display the CombatAdvantage_All state, all regular consequences of the condition (such as the Rogue's Sneak Attack) are taken into account, if applicable. If enough users request it, I can add an "Unflankable" state to the campaign. In my opinion, this situation doesn't occur often enough to warrant such a measure as the Altitude workaround is quite reasonable. Of course, you can also simply "zero out" the GrantingCA field in the "to hit" dialog when attacking.
The Action Points Awards; does the DM have the ability to choose to apply this way or not? Sometime encounters are worth more than one, or less than one.
The number of completed encounters is represented by the ActionPoints property of the MPB token itself. For example, let's say the party has completed three encounters in the current game day. Running the "Begin Encounter" macro at this point will cause the ActionPoints property to change from 3 to 4. If your players have just completed a double encounter, you can reflect that fact by manually increasing this value by one. For encounters that don't count toward a milestone, decrease this value by one.
In the Turn Enforcement; what is the process when a token grants actions to other tokens, as part of its turn? Can that token act? If not, can this be turned off?
Yes This page wasn't as clear as it could have been so I added the line at the beginning. Good catch.
In your Save Ends Both Support... well, maybe more of a question on your condition management; do you support multiple conditions from different sources? For example, Ongoing 10 Acid (save ends) from one monster, and Ongoing 20 Acid until the end of your next turn form another? Are they tracked independently, and is the right damage applied?
Yes, yes and ... maybe. Let's look at an example. Here is the actual code generated by the RACK for the Blackspawn Gloomweb's "Acidic Web" power:
Code: Select all
[IF(AllHits!=""), CODE: {
and is restrained (save ends both)
[MACRO("Register Effect@Lib:MacroPolicebox"): "Name=Acidic Web-Restrained; State=Restrained; Token="+Targets]
[MACRO("Register Effect@Lib:MacroPolicebox"): "Name=Acidic Web-OngoingAcid; Link=Acidic Web-Restrained; State=OngoingAcid; Property=CurrHP; Mod=15; Token="+Targets]
};{}]
Notice the "Link=Acidic Web-Restrained;" parameter in the second Register Effect line. This tells the MPB that when "Acidic Web-OngoingAcid" ends, "Acidic Web-Restrained;" must end as well. If the victim is subjected to a second OngoingAcid power (such as the wizard's "Acid Mire", for example), the two effects will stack because they have different names. However, if a second Blackspawn Gloomweb also places its Acidic Web on the victim then that token will
not take OngoingAcid 30 because the effect name is the same (i.e. the second overwrites the first).
This is my understanding of how ongoing damage is applied. If I am incorrect then please let me know and I will register this as a defect. In the meantime, it is very simple to work around the problem. Just change the names in the Register Effect lines of your monsters' powers as appropriate. See
this section for more information.
On that same note; does it track the type of bonuses that are applied to tokens ensure there are no like-bonuses over stacking? For example, when a spell gives a power bonus to a token’s attack roll, will the framework know if that token already has a power bonus to attack rolls; and thus not over stack the attack bonus?
Yes and no. OK, let's say a tiefling uses "Infernal Wrath" (+1 power bonus) and a fear power which makes use of his "Hellfire Blood" (+1 feat bonus) ability. Again, because these Register Effect lines will have different names, they will stack. However, what if a cleric casts "Lance of Faith" on the tiefling? The power bonuses will stack when they should not.
As with the Blackspawn Gloomweb, you need to adjust the names of the effects so they are the same. The easiest way to do this is to simply delete that parameter from the Register Effect lines so they both default to the state name (which is "AttackBonus" in both cases). Again, it would probably be easier to just handle the situation manually.
Is there support for spell preparation (spellbooks)?
No, this must be tracked manually. As my home game now has a wizard, I will make this a priority for Beta 6. In the meantime, you can just rearrange the powers on your personal library token. Daily spells the wizard has chosen to use that game day can go in the "Daily" group while unusable ones can be relegated to a group called "Spellbook" (or whatever).
Is there support for tokens other than PC’s and NPC’s? For example; traps and hazards that may or may not be attackable?
Yes
The language support sounds neat. In a powers' output, can you specify what PC’s see and what the DM sees? It would be nice to have little notes for the DM when a power is run. Sometimes posting everything is not appropriate.
I didn't think of that but good suggestion! When typing in what the DM sees, you could probably phrase it like so: "[g: The troll springs from hiding at this point!]". Square brackets can be problematic for the macro language at times but I know a few sneaky ways to get around this problem. This is the technique the MPB presently uses for notifying you about power recharges (see earlier post in this thread).
Fire Beetle.xml
Please try again until the attack has concluded. Thanks!