[4E] Rumble's "Slim" Framework

[Rumble]

Hmmmm I just had a REALLY crazy thought that I a m not sure how well if at all it will work. What if copy token were used to make a condition token which knows on who the condition applies, shows up in in init(or not if the GM made them not visible to players as an option) and held whatever information was needed about the condition to make it do stuff when it got it's initiative.

How workable would something like that be?

So, like a condition object, in a way? It knows it's type, it's victim, it's source, and how long it lasts? And then appears in initiative before or after the triggering source, for instance?

[jfrazierjr]

Hmmmm I just had a REALLY crazy thought that I a m not sure how well if at all it will work. What if copy token were used to make a condition token which knows on who the condition applies, shows up in in init(or not if the GM made them not visible to players as an option) and held whatever information was needed about the condition to make it do stuff when it got it's initiative.

How workable would something like that be?

So, like a condition object, in a way? It knows it's type, it's victim, it's source, and how long it lasts? And then appears in initiative before or after the triggering source, for instance?

Yea, thats what I was thinking. It also would eliminate the need for largish JSON structures stored somewhere(and being constantly updated and all that entails with putToken(). Basically, it could be created and added to the initiative list above/below the affected tokens. Bad thing is that it would clutter up the init list with more entries. <shrug>

I know people have complained forever about not being able to copyToken() and modify in one macro. I don't think it would be too hard to maked a createToken() macro as long as what is passed to it is fairly limited in terms of data information. In theory, if you name the tokens correctly, you could even use some fancy findToken() parameters to get the conditions from the condition tokens instead of storing on the affected tokens for building a "my conditions" frame.

Anywhoo...just a thought

[Rumble]

Until there's a good "makeToken()" or creatToken() function, I don't want to play around too much with copyToken(). I seem to have ironed out some of the last few things in this (like scripted condition stuff working with the tracking frame, and whatnot).

I'm stripping fully automated condition expiration from this framework - or rather, fully automated based-on-turn-sequence condition expiration. It's the hardest thing to do right, and it's never quite right, so it it's being removed in favor of the condition tracking frame.

I've also made the condition cards the default tooltip for anything I have a condition card for (which is basically the major conditions, absent ongoing damage).

I'm busy porting these features over to the Gamma World incarnation of this framework, but after that, it should be wrapped up except for bugfixing.

[jfrazierjr]

Until there's a good "makeToken()" or creatToken() function, I don't want to play around too much with copyToken(). I seem to have ironed out some of the last few things in this (like scripted condition stuff working with the tracking frame, and whatnot).

I'm stripping fully automated condition expiration from this framework - or rather, fully automated based-on-turn-sequence condition expiration. It's the hardest thing to do right, and it's never quite right, so it it's being removed in favor of the condition tracking frame.

I've also made the condition cards the default tooltip for anything I have a condition card for (which is basically the major conditions, absent ongoing damage).

I'm busy porting these features over to the Gamma World incarnation of this framework, but after that, it should be wrapped up except for bugfixing.

Well... you have SVN, so as long as you keep a narrow focus, such a function should not need to be overly complicated. Basically, you need token name, imageid, property type, and perhaps a property map (JSON object) to set the data. I think that should cover it... Not trying to twist your arm or anything though.... Once you have the tokenId, call putToken() to add to the map and return the tokenid back to the caller.

[Doc_Waldo]

Good move on the removing auto conditions. I think just figuring out a way or place to make adjustments to the conditions/state list is all that is needed.

Did you post your update yet?

[Rumble]

Good move on the removing auto conditions. I think just figuring out a way or place to make adjustments to the conditions/state list is all that is needed.

Did you post your update yet?

No, not yet. As for make adjustments - do you mean the ability to edit an existing condition (so if you make a mistake, or if stunned turns to unconscious, or something?) At this point, my opinion on that is "delete it and add a new one." However, editing isn't that big a deal, I think, if that's what you're asking about.

[Doc_Waldo]

No, sorry. I am talking about being able to quickly add, say "shroud 2", etc. Another state, conditions as they arise. So basicly someone would add the image, and then just have to know where to go to add the name to the list. The final step would be to somehow be able to fill out a form, or area in the code for the card update. Basically treating the conditions much like powers. Since they really are one of the major parts of DMing and they seem to change a lot, or at least it because a part of the DM's area where he can add some flavor, i.e. change icons, maybe a little wording, etc.

Although I wasn't thinking at first, if there was a way to handle conditions like your power manager, "edit" them, and "add" them. Since the cards, I am assume are built via grabbing data, hopefully each card could be wrapped. A default card and a default icon could be established, with the ability to change and/or add the icon state.

Of course that is the complex version. At the min, I think it would be great just to be able to add and adjust conditions, even from code if necessary.

When we play, conditions are probably the biggest help and/or problem. Last night we had an incredible battle, and guys were getting 5-6 different conditions. Having the ability to add "reminder" states, as you have would have been great, and more important, having the docked managed states, as you have would have been great.

Anyway, long answer to your question. I'm speaking of the adding and editing states in the framework.

[Rumble]

No, sorry. I am talking about being able to quickly add, say "shroud 2", etc. Another state, conditions as they arise. So basicly someone would add the image, and then just have to know where to go to add the name to the list. The final step would be to somehow be able to fill out a form, or area in the code for the card update. Basically treating the conditions much like powers. Since they really are one of the major parts of DMing and they seem to change a lot, or at least it because a part of the DM's area where he can add some flavor, i.e. change icons, maybe a little wording, etc.

Anyway, long answer to your question. I'm speaking of the adding and editing states in the framework.

Ah, okay. Well, a few things to consider:

1) The cards are fixed images generated by someone else - they're not editable, and they're only available for the following conditions:

Blinded, Dazed, Deafened, Dominated, Dying, Grabbed, Helpless, Immobilized, Marked, Petrified, Prone, Restrained, Slowed, Stunned, Surprised, Unconscious, Weakened

When you view a card, you're viewing an image summoned from a table, not something constructed by the framework. So there's no capacity in the framework to add cards or edit their contents unless you want to generate the graphics and insert them into the table in the relevant location, and I don't plan on adding any capability to generate a card like that.

2) To add new conditions, you'd need to do basically 3 steps in the final update:

a. Add the new state image to the Campaign Properties.
b. Decide what list it fits in best - Basic, Modifier, Feature, or Damage
c. Add it to the corresponding property on the Lib:4e token. For example, if you added "Shroud_2" to the campaign properties, you'd want to then go to the Lib:4e token, find the property FEATURE_STATES, and add "Shroud_2" to that list.

After that, it should appear in the proper windows and be handled as necessary by the framework.


The final update is now available (appropriately named DD4E_Slim_final). It removes all but the frame-tracked condition management, which is integrated with both saving throws and damage/healing (so a player token that becomes dying will have that condition show up in the tracking frame).

[Rumble]

And, of course, I forgot something - please import the following macro to "Lib:PowerLibrary" so you can also edit NPC powers.

[Doc_Waldo]

OK, that makes sense. I thought the cards where generated by you in html. Thanks.

[Doc_Waldo]

Quick question. On the Miscellaneous tab in the Edit Character dialogue, what does "Use Inherent/Fixed Bonuses:" mean and/or do? Is this linked to not using magic weapons?

[Rumble]

Quick question. On the Miscellaneous tab in the Edit Character dialogue, what does "Use Inherent/Fixed Bonuses:" mean and/or do? Is this linked to not using magic weapons?

Yep, that's what it does - the Inherent Bonuses are pulled from a table based on the chart in the Dark Sun book (it uses the same numbers as DMG2, but it also has critical bonus dice guides).

[Doc_Waldo]

I have a list of some possible errors. Do you want me to post them here or somewhere else? Most of them are easy enough to work around but there are two that stand out.

1) When a player takes damage, they automatically take on the state/condition of "DYING'. Regardless of what the HP's are it could be 50 HP's and then take 5. It happens whether the DM gives it to them for campaign macro's, in and/or out of initiative. Strangely, the NPC's work fine.

2) When doing a full clearing of initiative, it closes the conditions frames automatically.

The others may or may not be bugs, so I won't post until you let me know where.

Clarification questions:

A) Concerning consumables. I noticed that when I entered an amount in the "recharge" field it showed up on the marco button label; however, I couldn't figure out how to get it to keep track when used. Reason I ask, is that when you chose "consumable", it automatically places " ( ) " next to the name. Is there suppose to be a way to keep track of the consumables?

B) Is there a way to make it so when you use a ranged weapon it automatically grabs the ranged weapon? Or is the purpose of having them switch to force an action. Meaning, currently if you have your melee weapon equipped, when you use a ranged weapon, it just uses the melee weapon. I wondering because when a player does changed equipped gear, nothing comes out in chat so there is no way of knowing anyways.

C) Can the players view the conditions window or attackable frame for themselves and the others?

Thanks.

[Rumble]

I have a list of some possible errors. Do you want me to post them here or somewhere else? Most of them are easy enough to work around but there are two that stand out.

1) When a player takes damage, they automatically take on the state/condition of "DYING'. Regardless of what the HP's are it could be 50 HP's and then take 5. It happens whether the DM gives it to them for campaign macro's, in and/or out of initiative. Strangely, the NPC's work fine.

That's a bug; I was horsing around with getting the condition frame to work with Dying, and I must have made a mistake.

2) When doing a full clearing of initiative, it closes the conditions frames automatically.

That's intentional - or, it was with good intentions, let's say. I was picturing "clear completely" as "shut it all down." I can eliminate the closing of other panels, though; you'll have to make sure to reset them manually (there's a button on Lib:4e to do so, I think).

The others may or may not be bugs, so I won't post until you let me know where.

Post them here.

Clarification questions:

A) Concerning consumables. I noticed that when I entered an amount in the "recharge" field it showed up on the marco button label; however, I couldn't figure out how to get it to keep track when used. Reason I ask, is that when you chose "consumable", it automatically places " ( ) " next to the name. Is there suppose to be a way to keep track of the consumables?

The "consumables" flag is primarily used to change the button color to yellow - there's no inventory tracking. The recharge field is for the recharge values rolled on the die round to round to see if something recharges; not the number of items you have. The framework should gray out a rechargeable power once used.

B) Is there a way to make it so when you use a ranged weapon it automatically grabs the ranged weapon? Or is the purpose of having them switch to force an action. Meaning, currently if you have your melee weapon equipped, when you use a ranged weapon, it just uses the melee weapon. I wondering because when a player does changed equipped gear, nothing comes out in chat so there is no way of knowing anyways.

No, there's no way to do that (obviously, there are ways to do that, just not implemented). When the player swaps gear, the change is reflected in their token statsheet (but not chat, you're right. I can add a report to chat that says they switched to a new weapon). Since the framework doesn't check range or anything, it doesn't really care what weapon it's using, it just goes to the slot (main hand, off hand) and uses whatever's there. I could make that a bit smarter, though, and at least throw a warning that says "You're using a ranged power, but you have a melee weapon equipped!" This also reminds me that I do not have a "use my off-hand weapon" option in the targeting window. I used to...wonder where it went.

C) Can the players view the conditions window or attackable frame for themselves and the others?

The players cannot see the condition window (or actually, they probably could if they ran the macro from the Campaign Window) - they don't see it by default. I don't know what you mean by the "attackable frame" but if you mean the targeting frame, no - that only pops up on the local machine when a power is run.

[Doc_Waldo]

That's intentional - or, it was with good intentions, let's say. I was picturing "clear completely" as "shut it all down." I can eliminate the closing of other panels, though; you'll have to make sure to reset them manually (there's a button on Lib:4e to do so, I think).

What do you mean by "closing of other panels"? and "Reset them manually"? Can you give me a little run down on what they are for? I'm a little unclear by what you mean "reset them manually".

The "consumables" flag is primarily used to change the button color to yellow - there's no inventory tracking. The recharge field is for the recharge values rolled on the die round to round to see if something recharges; not the number of items you have. The framework should gray out a rechargeable power once used.

I don't see a flag. When I create a consumables power, the Macro button title shows up as "Alchemists Fire ()". It's the " () " that I'm wondering about. I'm haven't seen the button turn yellow either. So really just wondering about the " () " that append to the macro name, wanting to make sure not doing anything wrong.

(but not chat, you're right. I can add a report to chat that says they switched to a new weapon). Since the framework doesn't check range or anything, it doesn't really care what weapon it's using, it just goes to the slot (main hand, off hand) and uses whatever's there.

The only reason I asked about the switching between range and melee weapons is that when I was creating the powers for an Artificer, I noticed he had several that work for either melee or range, it depending what weapon he was using. I didn't want to make two power buttons, because they are exactly the same save the weapon attack bonus and/or damage. I did try and do specific "ranged" and "melee" powers for each and thought it may then grab the right inventory weapon, based upon the type of attack, i.e. ranged/melee. When it didn't I figured it was to keep the players honest in making sure they switch weapons with actions, but since nothing is spit out to chat, the DM has no way of knowing. Then it is on the player to just remember to switch, which is fine. I was just making sure I wasn't doing something wrong.

I could make that a bit smarter, though, and at least throw a warning that says "You're using a ranged power, but you have a melee weapon equipped!"

No sure how others feel, but I personally like the fact that it doesn't do anything with ranged, i.e. a warning coming up. That is easy enough for the players and DM and hopefully keeps the framework slimmer and faster.

The players cannot see the condition window (or actually, they probably could if they ran the macro from the Campaign Window) - they don't see it by default.

With many of the DnD 4e's powers having a conditions/state, benefit until a turn ends, etc. I create a lot of custom scripts that just add reminders notes, and wanted to make sure they had access to at least see the list, although I know they can view conditions via their conditions macro.

Also, I meant attachable, not attackable