[Rumble 5.1.3]: Custom Mods
Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice
Re: [Rumble 5.1.3]: Custom Mods
It's really a matter of how much time/inclination my coder player has
I don't see the aftereffects/failed saves being a common enough issue for it to be high priority for us. We're starting a new campaign and are focusing on the issues we need to get it going. That's not to say it will never happen, but it probably won't be imminent.
The "multiple conditions" issue is something that might come into play, so he might be more interested in addressing it. I'll bring your post to his attention and see what he says.
I don't see the aftereffects/failed saves being a common enough issue for it to be high priority for us. We're starting a new campaign and are focusing on the issues we need to get it going. That's not to say it will never happen, but it probably won't be imminent.
The "multiple conditions" issue is something that might come into play, so he might be more interested in addressing it. I'll bring your post to his attention and see what he says.
Re: [Rumble 5.1.3]: Custom Mods
I totally agree. Aftereffect/failed saves can be easily contained into the effects description text. Also I advise you to make them bold or in italics.Colmarr wrote: I don't see the aftereffects/failed saves being a common enough issue for it to be high priority for us.
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
There are several powers in the Wizard repertoire that would help by this. But the powers are not common taking in to account all classes, agreed.Ghiolekk wrote:I totally agree. Aftereffect/failed saves can be easily contained into the effects description text. Also I advise you to make them bold or in italics.Colmarr wrote: I don't see the aftereffects/failed saves being a common enough issue for it to be high priority for us.
There are lots of workarounds… The biggest being remembering.
Re: [Rumble 5.1.3]: Custom Mods
I'm told that neither of those functions are high on the list of priorities, unfortunately.
To make up for it, I'll post in the next few days mods that track death saves (and that make you automatically prone when you gain the Dying condition) and that allow you to include skill rolls in powers (useful for my monk PC, whose powers include a lot of "Make an Athletics check with a +5 bonus").
To make up for it, I'll post in the next few days mods that track death saves (and that make you automatically prone when you gain the Dying condition) and that allow you to include skill rolls in powers (useful for my monk PC, whose powers include a lot of "Make an Athletics check with a +5 bonus").
Re: [Rumble 5.1.3]: Custom Mods
Thank you. Thanks to your player as well. I could get flowery and hyperbolic, but my day is only just getting started, so my energy really only affords me candor instead. Let me just say I am extremely pleased and excited to see new improvements being made to a fine combat framework where I had given up on there being any more.
I made a framework for Exalted 2.5E.
Re: [Rumble 5.1.3]: Custom Mods
Hi all again,
This thread has been quiet. Quite a testament of how robust the framework is.
A few feature that the framework does not support are;
Brutal Weapons and feats that allow you to re-roll 1's and 2', etc; are likely much harder to in-cooperate.
I'll leave these ideas up for discussion.
EDIT: Oops, it does support Brutal Weapons... Just not where I thought it would be (under the weapon vs. each power). This method requires you to change every power when you equip a Brutal weapon, which is painful. Or can you use the XdYrN method in the equipment section too? Might be a better place for the tip?
This thread has been quiet. Quite a testament of how robust the framework is.
A few feature that the framework does not support are;
- Flying
Brutal Weapons
Brutal Weapons and feats that allow you to re-roll 1's and 2', etc; are likely much harder to in-cooperate.
I'll leave these ideas up for discussion.
EDIT: Oops, it does support Brutal Weapons... Just not where I thought it would be (under the weapon vs. each power). This method requires you to change every power when you equip a Brutal weapon, which is painful. Or can you use the XdYrN method in the equipment section too? Might be a better place for the tip?
Re: [Rumble 5.1.3]: Custom Mods
Looks like you can. Can anyone confirm this works?Deadolus wrote:... can you use the XdYrN method in the equipment section too? Might be a better place for the tip?
Re: [Rumble 5.1.3]: Custom Mods
Removing the Dying condition
Current:
I'm not sure whether the problem this mod is aimed at is inherent to Rumble 5.1.3 or if it was in fact introduced by some of the earlier mods. In any event, when a PC is dying and is then revived, it can be difficult to remove the Dying condition, even manually.
Proposed improvement:
Automatically remove the Dying Condition when a PC receives healing.
Method:
In the Lib:4e token, edit the Healing macro (it's in the group "Combat - Healing"). Find this code:
and insert the following immediately after it:
Outcome:
When a dying PC receives healing (including by rolling a 20 on a death saving throw and spending a surge), the dying condition is automatically removed.
Campaign file in OP updated.
Current:
I'm not sure whether the problem this mod is aimed at is inherent to Rumble 5.1.3 or if it was in fact introduced by some of the earlier mods. In any event, when a PC is dying and is then revived, it can be difficult to remove the Dying condition, even manually.
Proposed improvement:
Automatically remove the Dying Condition when a PC receives healing.
Method:
In the Lib:4e token, edit the Healing macro (it's in the group "Combat - Healing"). Find this code:
Code: Select all
[if(isPC()),CODE:
{
[h:switchToken(target)]
[h:CurrHP = hptot]
[h:bar.Health=CurrHP/MaxHP]
[h,if(CurrHP > 0),code:
{
[state.Dying = 0]
Code: Select all
[h:token = getName()]
[h:tokenSE = getConditions(token, 1)]
[tokenSE = json.remove(tokenSE,"Dying")]
[updateConditionTrack(token, tokenSE, 1)]
};{};]
[h,if(CurrHP > Bloodied),code:
{
[state.Bloodied = 0]
When a dying PC receives healing (including by rolling a 20 on a death saving throw and spending a surge), the dying condition is automatically removed.
Campaign file in OP updated.
Re: [Rumble 5.1.3]: Custom Mods
I just realised that I never came back and made good on this promise...Colmarr wrote:To make up for it, I'll post in the next few days mods that track death saves (and that make you automatically prone when you gain the Dying condition) and that allow you to include skill rolls in powers (useful for my monk PC, whose powers include a lot of "Make an Athletics check with a +5 bonus").
Unfortunately, I no longer have the email that set out my player's working, so I can't give you the step-by-step instructions. However, the campaign file attached to the OP (c7 and above) includes the code for:
Automatically falling prone when Dying
Death Save Counter
Relevantly, gaining the Dying condition will automatically impose the Prone condition, and the framework will track Death saving throws (and add a mouseover-only icon showing how many have been failed).
Re: [Rumble 5.1.3]: Custom Mods
I can. Works fine for Zeitgeist fireams, which all have the brutal property.Deadolus wrote:Looks like you can. Can anyone confirm this works?Deadolus wrote:... can you use the XdYrN method in the equipment section too? Might be a better place for the tip?
Re: [Rumble 5.1.3]: Custom Mods
This post is from a thread in the "Macros" forum in which Rumble asked me some questions about my framework. I felt it more appropriate to answer them here so programmers wishing to bolster his framework can take my ideas and run with them if they wish:
Yes I know you group your macros by action types and keep them all on a single token but you're right about my structure and process flow. There are barely any macros on the Avatar, usually less than 10 in fact. Each button calls one macro which displays a list of all macros it finds in the corresponding group on the Code Lib one.
For example, one of the buttons on the Avatar is called "At-Will". Pressing this calls the "Run Power" macro on MyLibToken. "Run Power" then looks at the Code Lib and finds the macro group called "At-Will" (because that's the label it read on the button). It gets the labels of all buttons in that group and presents this list to the user to choose from. It doesn't matter if there are 5, 25 or 100 buttons in that group. Although the menu may have 100 items in it, you still only need one "At-Will" button.
The "Code Lib" token can get quite large (up to 100K or so) but is never updated (no need since the Avatar holds all the data) so we don't need to worry about MapTool firing it around to multiple players. Because there is only a grand total of 10 lines of code on the Avatar (one "Run Power" call per button) and about 3 dozen properties, the resulting rptok can be as small as 10K. This is assuming the display JPEG is 2K and no portrait has been selected. Even with low network bandwidth and players in other cities, we've noticed MapTool has no trouble keeping up with token updates.
Keeping track of individual power macros can get tedious (because they're all uniquely coded) but the only other down side I can see to this approach is the need to continually cut and paste twice as many tokens to the next map. I will be looking into the "Teleport Pad" drop-in feature to solve this problem. Until then, it isn't that big a deal. Hopefully this clarifies.
Think of this as a sort of "binary token" solution. Each player has two tokens, one to move around the battlefield (i.e. "Avatar", as you say) and the other which acts as a sort of golfer's caddy. This caddy (or "Code Lib", as you say) token is unique to each player. It contains the same power macros as yours except it calls my master framework token ("MyLibToken" in your example above). The Avatar calls it caddy any time it needs to run a daily, encounter, etc.Rumble wrote:StarMan wrote:That's sort of what I do in my framework. All player data stays on the "avatar", as you say, while all the player's powers stay on the Lib token. Of course, this arrangement is in keeping with the usual "Keep your code and data separate." paradigm. Yes, it did take a bit of work but was worth it in the end.aliasmask wrote:I've been toying with the idea of avatars, where the players control a marker, but all the data is on a related lib token. But this could potentially be a lot of work.
The result is a minimalist player token (approx 33% the size of a Rumble token) which acts as a client to the static "server" Lib. As soon as I did this, any lingering lag problems disappeared because the avatar was WAY smaller than the original amalgamated solution.
As for your "token name (backup)" idea, continually polling for token moves might prove expensive in terms of performance. Maybe a periodic findToken() call could serve the same purpose?
Interesting idea. I'm thinking you wouldn't need anything at all on the Avatar token except macros and a single property that names the corresponding Lib token. Do you have another lib token with the actual macros on it (so, for instance, your Avatar has a button called Attack. This button simply says
This hits a UDF on the Code Lib Token, which refers to the actual attack function, which refers to the proper lib token for getting and setting data, and then the Avatar is just updated?Code: Select all
[r:execute("Attack", "MyLibToken")]
Is that how it's structured? Or how do you structure it - that might be an interesting project to undertake (and also, I guess it means you can have multiple avatar tokens and it's not such a tragedy if you accidentally delete something!)
Yes I know you group your macros by action types and keep them all on a single token but you're right about my structure and process flow. There are barely any macros on the Avatar, usually less than 10 in fact. Each button calls one macro which displays a list of all macros it finds in the corresponding group on the Code Lib one.
For example, one of the buttons on the Avatar is called "At-Will". Pressing this calls the "Run Power" macro on MyLibToken. "Run Power" then looks at the Code Lib and finds the macro group called "At-Will" (because that's the label it read on the button). It gets the labels of all buttons in that group and presents this list to the user to choose from. It doesn't matter if there are 5, 25 or 100 buttons in that group. Although the menu may have 100 items in it, you still only need one "At-Will" button.
The "Code Lib" token can get quite large (up to 100K or so) but is never updated (no need since the Avatar holds all the data) so we don't need to worry about MapTool firing it around to multiple players. Because there is only a grand total of 10 lines of code on the Avatar (one "Run Power" call per button) and about 3 dozen properties, the resulting rptok can be as small as 10K. This is assuming the display JPEG is 2K and no portrait has been selected. Even with low network bandwidth and players in other cities, we've noticed MapTool has no trouble keeping up with token updates.
Keeping track of individual power macros can get tedious (because they're all uniquely coded) but the only other down side I can see to this approach is the need to continually cut and paste twice as many tokens to the next map. I will be looking into the "Teleport Pad" drop-in feature to solve this problem. Until then, it isn't that big a deal. Hopefully this clarifies.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!
Re: [Rumble 5.1.3]: Custom Mods
Very interesting.
My coder player had commented that slow performance was in part due to how much information each token was carrying, and could be improved by moving that information off-token.
The change required to fix that is pretty core to the whole framework though, and I imagine it's a significant amount of work, so followers of this thread shouldn't hold their breath for me to produce it
My coder player had commented that slow performance was in part due to how much information each token was carrying, and could be improved by moving that information off-token.
The change required to fix that is pretty core to the whole framework though, and I imagine it's a significant amount of work, so followers of this thread shouldn't hold their breath for me to produce it
-
- Kobold
- Posts: 13
- Joined: Sun Dec 26, 2010 5:36 pm
Re: [Rumble 5.1.3]: Custom Mods
I was trying to use your Aura mod to set up the Boiling Cloud power, where the Boiling Cloud button would turn on the aura and the Boiling Cloud Attack power would turn it off. However, I've run into a strange issue where the aura mod doesn't work on attack powers, only Personal powers and such. Any reason why that would be?
Also, the text in your post is wrong - it's 'Auras', not 'Bursts'. And 'Burst1' is 'Burst1Cassi' for some reason.
Also, the text in your post is wrong - it's 'Auras', not 'Bursts'. And 'Burst1' is 'Burst1Cassi' for some reason.
Re: [Rumble 5.1.3]: Custom Mods
Thanks. I've edited the relevant post.ForteMaster wrote:The text in your post is wrong - it's 'Auras', not 'Bursts'. And 'Burst1' is 'Burst1Cassi' for some reason.
I've just checked my PC Bard, who has the Verse of Triumph attack power. The power is set up this way:ForteMaster wrote:However, I've run into a strange issue where the aura mod doesn't work on attack powers, only Personal powers and such. Any reason why that would be?
Power window
Macro
The only difference I can see between that and the Automated Auras instructions I posted earlier is that the aura toggling code is before the attack line in the macro, rather than after. Assuming the problem isn't at your end, maybe there's something in the language that requires the aura code to come before the attack.
Re: [Rumble 5.1.3]: Custom Mods
Me: Done!
You: “Done”? Done what?
Me: All of it. Well … most of it.
You: Most of what?
Me: All the changes discussed in this thread (and plenty more) except the beast druid image change (very cool, BTW) and AFK ones.
You: So what, StarMan? We’ve done them too and attached the Rumble campaign to boot.
Me: That’s not what I mean. For a full feature list, please visit the “Transition Guide” section of my site: Merry Christmas, everyone!
PS: This is the fruition of my "You heard it here first, folks!" post near the bottom of this page. I will try to fix the training videos problem over the next few days.
You: “Done”? Done what?
Me: All of it. Well … most of it.
You: Most of what?
Me: All the changes discussed in this thread (and plenty more) except the beast druid image change (very cool, BTW) and AFK ones.
You: So what, StarMan? We’ve done them too and attached the Rumble campaign to boot.
Me: That’s not what I mean. For a full feature list, please visit the “Transition Guide” section of my site: Merry Christmas, everyone!
PS: This is the fruition of my "You heard it here first, folks!" post near the bottom of this page. I will try to fix the training videos problem over the next few days.
StarMan - The MacroPolicebox D&D 4E Framework: Import ANYTHING!