Chrome, Firefox 3 and 4, Safari, and Internet Explorer all do the button thing.Colmarr wrote:Huh, so it works in Chrome? Ok, must be a browser thing then.Kryx wrote:Using Chrome it is exactly as you described in the first paragraph.
[Rumble 5.1.3]: Custom Mods
Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice
Re: [Rumble 5.1.3]: Custom Mods
Re: [Rumble 5.1.3]: Custom Mods
Cool. I'd seen the 'wall of black'-type spoiler on RPTools before, so assumed it didn't use the open/close sort.Rumble wrote:Chrome, Firefox 3 and 4, Safari, and Internet Explorer all do the button thing.
Beast form post edited accordingly. Thanks all.
Edit: One server at my work displays open/close spoilers. The other displays wall-of-black. Both are IE 8. Weird, but I guess ultimately irrelevant!
Re: [Rumble 5.1.3]: Custom Mods
At-Will stances do not end at the end of an encounter. It is fine for a Knight to always have a stance up. See Rules Compendium page 120.Colmarr wrote: Currently, the framework does not end essentials stances at the end of the encounter. Once a token is in a stance, it stays in one. This can cause (minor) problems when, for example, a Knight gets a surprise round and is in a stance it should not be in.
Proposed improvement:
Automatically end stances when the PC takes a short or extended rest.
Outcome:
When the PC takes a short or extended rest, all stances on the token should turn off.
Re: [Rumble 5.1.3]: Custom Mods
Learn something new every day!spayne wrote:At-Will stances do not end at the end of an encounter.
I've amended the relevant post to mention that. Thanks
Re: [Rumble 5.1.3]: Custom Mods
SPEED CHANGE CONDITION
Current:
The framework handles and tracks the slowed condition, and allows you to manually edit a token's speed, but does not automate speed changes from powers such as Razorclaw Shifting.
Proposed improvement:
Create a condition that records and tracks speed changes.
Method:
Buckle up. This one's a long one.
Go to your campaign properties and into the States tab.
Add a new state named SpeedChange. Its 'group' is Movement, 'type' is Grid Image, 'grid size' is 3x3. Pick an appropriate icon to represent it (this is the icon that will appear on the token when the condition is in effect). I used the 'running person'.
Still in Campaign Propeties, move to the properties tab. Add a new property called MoveAdjusts.
Find the Lib:States4e token and edit it. In the token properties, add SpeedChange next to the entry for MoveAdjusts and add SpeedChange to the list of conditions next to the entry for AllConditions.
In the selection window, find and edit the onCampaignLoad macro. Add this text to the end of the macro:
Save the changes, close the edit window, then click on the macro to run it.
Find and edit the procStates macro. Find this text:
and add this text below it:
Find and edit the handleStates macro. Find this text:
and add this text below it:
Create a new Macro (rick click in the selection window and select 'new'). Name the new macro procTempMovement. Edit it to make its group 'Movement Handling'. Paste the following text into the new macro:
Find and edit the procAllyStates macro. Find this text:
and insert this text after it:
Still in procAllyStates, find this text:
and add this text below it:
Intermission: The above mods create and integrate the new Speedchange condition. The following mods allow that condition to auto expire.
Select the Lib:States4e token and open its selection window. In the expireCondition macro, find this text:
and beneath it add:
Then find this text:
and beneath it add:
Then find:
and beneath it add:
In the selection window, create a new macro. Call it restoreMovement and allocate it to group Bonus & Penalty Handling. Paste this text into the new macro:
Outcome:
When you go into the power edit screen, your list of available conditions will now include SpeedChange. Eg. If you add a SpeedChange condition to a power, with a duration of End of Encounter and give it the value 2, the token's speed will increase by 2 until the end of the encounter.
I must say that after following all these instructions, I have a new respect for my player and Rumble.
Current:
The framework handles and tracks the slowed condition, and allows you to manually edit a token's speed, but does not automate speed changes from powers such as Razorclaw Shifting.
Proposed improvement:
Create a condition that records and tracks speed changes.
Method:
Buckle up. This one's a long one.
Go to your campaign properties and into the States tab.
Add a new state named SpeedChange. Its 'group' is Movement, 'type' is Grid Image, 'grid size' is 3x3. Pick an appropriate icon to represent it (this is the icon that will appear on the token when the condition is in effect). I used the 'running person'.
Still in Campaign Propeties, move to the properties tab. Add a new property called MoveAdjusts.
Find the Lib:States4e token and edit it. In the token properties, add SpeedChange next to the entry for MoveAdjusts and add SpeedChange to the list of conditions next to the entry for AllConditions.
In the selection window, find and edit the onCampaignLoad macro. Add this text to the end of the macro:
Code: Select all
[h:defineFunction("procTempMovement", "procTempMovement@this")]
[h:defineFunction("restoreMovement", "restoreMovement@this")]
Find and edit the procStates macro. Find this text:
Code: Select all
[h:vlnAdjust=getLibProperty("VAdjusts")]
Code: Select all
[h:MAdjust=getLibProperty("MoveAdjusts")]
Code: Select all
[if(state == "Insubstantial"): procInsub(0)]
[if(state == "Invisible"): setVisible(0)]
Code: Select all
[if(listFind(MAdjust,state)!=-1):procTempMovement(state,newDmgVal)]
Code: Select all
[h:assert(argCount() == 2, "procTempMovement() requires exactly 2
arguments", 0)]
[h:state = arg(0)]
[h:amount = arg(1)]
[h:Speed = Speed + amount]
Code: Select all
[h:vlnAdjust=getLibProperty("VAdjusts")]
Code: Select all
[h:MAdjust=getLibProperty("MoveAdjusts")]
Code: Select all
[h,if(listFind(vlnAdjust,state)!=-1):procTempVulnerable(state,val)]
Code: Select all
[h,if(listFind(MAdjust,state)!=-1):procTempMovement(state,val)]
Select the Lib:States4e token and open its selection window. In the expireCondition macro, find this text:
Code: Select all
[h:tokenET = getConditions(token, 0)]
[h:tokenSE = getConditions(token, 1)]
[h:tokenOD = getConditions(token, 2)]
Code: Select all
[h:changeValue = json.get(condInfo, "ogDamAmt")]
Code: Select all
[h:rvAdjust =getLibProperty("RVAdjusts")]
Code: Select all
[h:MAdjust =getLibProperty("MoveAdjusts")]
Code: Select all
[h,if(listFind(rvAdjust,condition)!=-1): restoreRV(condition)]
Code: Select all
[h,if(listFind(MAdjust,condition)!=-1): restoreMovement(condition, changeValue)]
Code: Select all
[h:assert(argCount() == 2, "restoreMovement() requires exactly 2 argument", 0)]
[h:defAdjSource = arg(0)]
[h:changeValue = arg(1)]
[h:setProperty("Speed", Speed-changeValue)]
When you go into the power edit screen, your list of available conditions will now include SpeedChange. Eg. If you add a SpeedChange condition to a power, with a duration of End of Encounter and give it the value 2, the token's speed will increase by 2 until the end of the encounter.
I must say that after following all these instructions, I have a new respect for my player and Rumble.
Re: [Rumble 5.1.3]: Custom Mods
AUTOMATED AURAS
Current:
The framework supports auras (by which I am referring to shaded squares around a token, not the 'aura' powers used in 4e) and includes an impressive list of them, but does not support applying them as a consequence of power usage.
Proposed improvement:
Automatically apply an aura when an associated power is used.
Method:
Create the relevant power for your token as normal. For example, the Knight's defender aura power would look like this:
Then edit the power's macro. Insert this code at the end:
Outcome:
When you click the power macro, the aura will appear. When you click the macro again, the aura will disappear.
If you want an aura other than medium burst 1, you can replace MediumAuras and Burst1 in the above code with the appropriate words to create the aura you're after.
Original post updated to attach the up-to-date custom mods file.
Edit: Post updated to reflect Fortemaster's later comments on page 3. Note that the attached file uses the lightsource Burst1Cassi because that's the Knight PC that uses this mod. Feel free to change the name of the light source to match your campaign.
Current:
The framework supports auras (by which I am referring to shaded squares around a token, not the 'aura' powers used in 4e) and includes an impressive list of them, but does not support applying them as a consequence of power usage.
Proposed improvement:
Automatically apply an aura when an associated power is used.
Method:
Create the relevant power for your token as normal. For example, the Knight's defender aura power would look like this:
Defender Aura
Code: Select all
[h,if(getLights("MediumAuras")==""),CODE:{
[h:setLight("MediumAuras", "Burst1",1)] };{ [h:setLight("MediumAura", "Burst1",0)] }]
When you click the power macro, the aura will appear. When you click the macro again, the aura will disappear.
If you want an aura other than medium burst 1, you can replace MediumAuras and Burst1 in the above code with the appropriate words to create the aura you're after.
Original post updated to attach the up-to-date custom mods file.
Edit: Post updated to reflect Fortemaster's later comments on page 3. Note that the attached file uses the lightsource Burst1Cassi because that's the Knight PC that uses this mod. Feel free to change the name of the light source to match your campaign.
Last edited by Colmarr on Tue Dec 06, 2011 6:55 am, edited 1 time in total.
Re: [Rumble 5.1.3]: Custom Mods
Thrilling!!!
Cheers Colmarr
Cheers Colmarr
Let's share our creativity: http://cid-be06ec931d4a4fa5.office.live ... e%20Tokens
http://groups.google.com/group/tokensrumble
http://groups.google.com/group/tokensrumble
Re: [Rumble 5.1.3]: Custom Mods
High Crit Damage
This isn't my coding or my players. It's Rumble's work but I'm including it here so anyone who looks through this thread has the mod in the same place.
To correctly implement High Crit damage (the 5.1.3 framework adds 1[W] to crits, not 1[W] per tier), follow the instructions here.
Campaign file in post #1 updated to include the fixed macros.
This isn't my coding or my players. It's Rumble's work but I'm including it here so anyone who looks through this thread has the mod in the same place.
To correctly implement High Crit damage (the 5.1.3 framework adds 1[W] to crits, not 1[W] per tier), follow the instructions here.
Campaign file in post #1 updated to include the fixed macros.
Re: [Rumble 5.1.3]: Custom Mods
Campaign file in post #1 updated to include bug fixes.
Re: [Rumble 5.1.3]: Custom Mods
AFK Marker
This isn't a functional mod. It's more an online play aid that reminds you when one of the players is AFK (away from Keyboard).
This code will create an AFK button that sits in a token's selection window next to End Turn. Clicking it will apply a visual AFK overlay to the token:
Clicking the macro again will remove the overlay.
Method
Create a new macro on the Lib:States4e token called AFK. I chose to put it in the top Lib:States4e group but I don't think the group is important.
Edit the new macro and insert this code:
Then go to Edit > Campaign Properties > States. Add a new state called AFK. The type is 'image'. You will need to provide an image to serve as the overlay. The one I used is attached. When you're happy with the appearance of the overlay, click 'add' to add the state to your campaign.
Then find Initialize Token - Alt macro on the Lib:4e token.
Find this code:
and add the following immediately below it:
Outcome:
The above steps create the AFK macro and mark it as one of the framework's default macros (along with melee basic assault, end turn etc). It will automatically be added to a token whenever you add the default macros from the campaign window (F4). All new tokens you create will get the AFK macro when you use F4. Pre-existing tokens will not automatically get the new macro, so you'll need to open them and use F4 to add the AFK macro.
This isn't a functional mod. It's more an online play aid that reminds you when one of the players is AFK (away from Keyboard).
This code will create an AFK button that sits in a token's selection window next to End Turn. Clicking it will apply a visual AFK overlay to the token:
Clicking the macro again will remove the overlay.
Method
Create a new macro on the Lib:States4e token called AFK. I chose to put it in the top Lib:States4e group but I don't think the group is important.
Edit the new macro and insert this code:
Code: Select all
[H: stateAFK = state.AFK]
[H: msg = if ( stateAFK == 1 , "<i>Back!</i>", "<b>A</b>way <b>F</b>rom <b>K</b>eyboard" ) ]
[H: state.AFK = if (stateAFK == 1, 0, 1 ) ]
[R: msg ]
Then find Initialize Token - Alt macro on the Lib:4e token.
Find this code:
Code: Select all
[h,if(!hasMacro("End Turn")): createMacro("End Turn", '[macro("EndTurn@Lib:States4e"):""]', "color=yellow; fontColor=black; sortBy=8; playerEditable=0; minWidth="+minWidth+";")]
Code: Select all
[h,if(!hasMacro("AFK")): createMacro("AFK", '[macro("AFK@Lib:States4e"):""]', "color=orange; fontColor=black; sortBy=9; playerEditable=0; minWidth="+minWidth+";")]
The above steps create the AFK macro and mark it as one of the framework's default macros (along with melee basic assault, end turn etc). It will automatically be added to a token whenever you add the default macros from the campaign window (F4). All new tokens you create will get the AFK macro when you use F4. Pre-existing tokens will not automatically get the new macro, so you'll need to open them and use F4 to add the AFK macro.
- Attachments
-
- AFK.png (7.57 KiB) Viewed 6891 times
Re: [Rumble 5.1.3]: Custom Mods
Back from dying but still bloodied
Current:
When healing a dying character, the framework correctly removes the dying icon, but does not add the bloodied icon if the healing leaves the token below it's bloodied value.
Proposed improvement:
Add the bloodied icon if healing does not return the dying character to hp above it's bloodied value.
Method:
Edit the Healing macro on the Lib:4e token.
Find this code:
and add the following immediately below it:
Then find this code:
and add this immediately below it:
Outcome:
When a token is healed to a hp total above dying but below bloodied, the framework will automatically add the bloodied icon.
Current:
When healing a dying character, the framework correctly removes the dying icon, but does not add the bloodied icon if the healing leaves the token below it's bloodied value.
Proposed improvement:
Add the bloodied icon if healing does not return the dying character to hp above it's bloodied value.
Method:
Edit the Healing macro on the Lib:4e token.
Find this code:
Code: Select all
[h,if(CurrHP > 0),code:
{
[state.Dying = 0]
};{};]
Code: Select all
[h,if(CurrHP > 0 && CurrHP < (Bloodied+1)),code:
{
[state.Bloodied = 1]
};{};]
Code: Select all
[h,if(CurrHP > 0),code:
{
[state.Dead = 0]
[setLayer("TOKEN")]
};{};]
Code: Select all
[h,if(CurrHP > 0 && CurrHP < (Bloodied+1)),code:
{
[state.Bloodied = 1]
};{};]
When a token is healed to a hp total above dying but below bloodied, the framework will automatically add the bloodied icon.
Re: [Rumble 5.1.3]: Custom Mods
Die at negative bloodied value
Current:
The framework marks NPC tokens as 'dead' when they reach 0 hp, but never marks PCs as dead, regardless of whether they have -1 or -1000 hp.
Proposed improvement:
Mark PC tokens as dead when they reach negative bloodied hit points.
Method:
There are two steps to this mod. Both steps are identical but take place in different macros. I'll combine them here for convenience.
In each of the Damage and GMDamage macros on the Lib:4e token, find the following code:
and replace it with:
Outcome:
When a PC token is reduced to negative bloodied hit points, it will get the same 'dead' overlay that NPC tokens get when they reach 0 hit points.
Note that this overlay is not removed if you then use the healing macros on the token. If the PC is returned to life, you'll need to manually remove the overlay by right-clicking on the PC token. Serves them right for dying...
Campaign file in OP updated.
Current:
The framework marks NPC tokens as 'dead' when they reach 0 hp, but never marks PCs as dead, regardless of whether they have -1 or -1000 hp.
Proposed improvement:
Mark PC tokens as dead when they reach negative bloodied hit points.
Method:
There are two steps to this mod. Both steps are identical but take place in different macros. I'll combine them here for convenience.
In each of the Damage and GMDamage macros on the Lib:4e token, find the following code:
Code: Select all
[h, IF(targPC), CODE:
{
[H: state.Dying = 1 - max(0,min(1,CurrHP))]
[H: state.Bloodied = 1 - max(state.Dying, min(1,CurrHP - Bloodied))]
Code: Select all
[h, IF(targPC), CODE:
{
[H: state.Dead = 1 - min(1,(Bloodied+CurrHP))]
[H: state.Dying = 1 - max(state.Dead,min(1,CurrHP))]
[H: state.Bloodied = 1 - max(max(state.Dying,state.Dead), min(1,CurrHP - Bloodied))]
When a PC token is reduced to negative bloodied hit points, it will get the same 'dead' overlay that NPC tokens get when they reach 0 hit points.
Note that this overlay is not removed if you then use the healing macros on the token. If the PC is returned to life, you'll need to manually remove the overlay by right-clicking on the PC token. Serves them right for dying...
Campaign file in OP updated.
Re: [Rumble 5.1.3]: Custom Mods
Both are really good updates - keep 'em coming!!
-- AidyBaby --
-- AidyBaby --
D&D qualities are related inversely to those of Poker... and I love both.
http://www.yorkpoker.co.uk
http://www.yorkpoker.co.uk
Re: [Rumble 5.1.3]: Custom Mods
Blinded shouldn't apply to close or area powers
Current:
Currently, the blinded condition applies an across-the-board -5 penalty to attack rolls. That penalty should not apply to area and close powers.
Proposed improvement:
Ensure that close and area powers don't take the -5 penalty.
Method:
In the Lib:4e token, edit the Process Attack macro. Find this text:
and add immediately below it:
Outcome:
Area and Close powers will not suffer a -5 penalty while the token is under the Blinded condition.
Current:
Currently, the blinded condition applies an across-the-board -5 penalty to attack rolls. That penalty should not apply to area and close powers.
Proposed improvement:
Ensure that close and area powers don't take the -5 penalty.
Method:
In the Lib:4e token, edit the Process Attack macro. Find this text:
Code: Select all
[h:concPen = max(blindPen,targetConcealedPen)]
Code: Select all
[h:concPen=if(attackType == "area" ||attackType == "close",0,concPen)]
Area and Close powers will not suffer a -5 penalty while the token is under the Blinded condition.
Re: [Rumble 5.1.3]: Custom Mods
- Back from dying but still bloodied
Die at negative bloodied value
Blinded shouldn't apply to close or area powers
Colmarr, if you are ambitious, I did have a request for Condition Aftereffects and On Failed Saves. Not sure if you feel you can tackle this one or not.
The only other functionality I think the FW needs is the ability to have the same condition applied two (or more) times. For example; allow for a Defence Bonus to AC & Reflex to be applied in addition to a Defence Bonus to AC. I have a fighter that gets one of these bonuses from a feat and the other from an item and should stack. Currently once the second Defence Bonus is applied, it over writes the first.
I have a few ideas on how this could work from a game mechanics stand point, but I am not a coder, so can't help there.
Keep up the great work!