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'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").

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.

This thread has been quiet. Quite a testament of how robust the framework is.

A few feature that the framework does not support are;

FlyingBrutal Weapons

Anyone willing to in-cooperate these? The flying could be just as simple as adding a new state. Range calculation functionality is not a must (and likely very hard), it could be as simple as the Reminder States, or even a renaming of "Reminder3", but allow for a value for squares above and below ground level. While at it (and while I think of it), a Burrowing state might be useful too.

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?

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:

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").

I just realised that I never came back and made good on this promise...

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 DyingDeath 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).

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:

Rumble wrote:

StarMan wrote:

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.

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.

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

Code:

[r:execute("Attack", "MyLibToken")]

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?

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!)

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.

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.

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

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.

The text in your post is wrong - it's 'Auras', not 'Bursts'. And 'Burst1' is 'Burst1Cassi' for some reason.

Thanks. I've edited the relevant post.

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?

I've just checked my PC Bard, who has the Verse of Triumph attack power. The power is set up this way:

Attachment:

Verse of Triumph.jpg [ 104.48 KiB | Viewed 1574 times ]

And the macro itself looks like this:

Attachment:

Verse of Triumph Macro.jpg [ 42.99 KiB | Viewed 1574 times ]

It works fine in my campaign file. Hitting the macro turns the aura on. Hitting it again turns the aura off (and you then cancel the attack).

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.

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 cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum