v 0.3.61 feature new itemCardId on damageOnlyWorkflow

[tposney]

In GitLab by @marcoseither on Feb 3, 2021, 21:47

Hi there, with v 0.3.61 you allowed using itemCardId: "new" for damageOnlyWorkflow, which really is a great addition as it adds the items style and description as well as the "apply damage buttons".

Three things could be improved:

• If this is used for a spell requiring concentration, it triggers the CUB concentrator, which I think should not be the case if you only want to show rolled damage in the styling of the item
• Maybe the buttons for rolling primary damage and for Applying Active Effects should be removed (same reason as above). As an optional feature there could be a button for rerolling the damage used to call the workflow.
• While the damage type is a parameter for the function, it is not shown on the item card.

[tposney]

Button delettion is a side effect of how the workflow is set up and the "new" simply follows the game settings. Might not be ideal but at least consistent.

Can you send me the json for the item so I can have a play. I don't implement my smites the same way so would be good to see another interpretation.

[tposney]

In GitLab by @marcoseither on Feb 6, 2021, 07:37

Sure :-) I attached the item and my macro for reoccuring effets, you'll need both for Searing Smite. The spell is not the final version though. Currently a player has to manually edit the spell and insert the stats of his melee weapon. I'm currently working on an automation for Booming Blade that loops through the the equipped items and lets the player choose the weapon he wants to use for the attack. As soon as this is finished I'll change Searing Smite accordingly.

fvtt-Macro-Reoccuring_Effect.json

fvtt-Item-Searing_Smite.json.

[tposney]

Have a look at the shillelagh spell in the DAE SRD spell it does that

[tposney]

In GitLab by @marcoseither on Feb 7, 2021, 18:10

Jeah, that's where I copied the coding from. You can have a Look at it here: https://gitlab.com/marcoseither/foundryautomation/-/tree/master/Spells/Level%200%20(Cantrips)

[tposney]

Was rereading the initial post. I think you're right about concentration should not be triggered. The only way I can influence cub concentrator is to not display the footeer (cub looks for that to determine concnetration) components, which is probably fine for damageonly/trap workflows.
So I've added that.
Apply active effects button is not displayed for damageonly workflows anymore.

I had a look at the macro and there were a few little changes I made, one for a bit of efficiency and one to fix an error condition. The efficiency is a property of the active effects, they have an origin, which points to the caster + item that applied the effect. So you don't need to loop through tokens to get to the caster

fvtt-Macro-Reoccuring_Effect_2.json

Changes will go out in midi-qol

[tposney]

In GitLab by @marcoseither on Feb 10, 2021, 19:37

That's great news. One question about the origins field. If I understand it correct, it only stores the ActorId and the OwnedItemId. It does not store the tokenId. While this is fine for linked tokens, it is somewhat tricky for unlinked ones. A horde of zombies all have the same actorId. If one of those zombies recieves a one-time upgrade by adding an additional feature/spell/item directly to it's character sheet, it gets quite troublesome. That's why I loop through the tokens and search for the item id. Even this method is not that great, because such one-time upgrades could also consist of attributes being increased. If I have 5 nps archmages with every archmage having the same spells (so all tokens have the same actorId and the same Ids for their owned items), but their leader having an increased intelligence score and as a result an increased spell dc - how do I find this one specific data without having the caster's tokenId to begin with?

Maybe having the tokenId also being stored in the origins field would be a great addition in simplifying the whole process of finding the correct data.

[tposney]

You are right and was hoping you did not have that case. I've raised this with atropos that the origin field is not flexible enough, it needs to support Token.id.ownedItem.id and for that to work correctly. I could make that the origin field "correct", but it would not work with the in-built functionality. I'm hoping that origin is upgraded to support tokens.

[tposney]

In GitLab by @marcoseither on Feb 11, 2021, 01:55

Thanks for the reply - such kind of flexibility would really be very helpful as it supports one of the strengths of Foundry - the ability to modify combat participants on the fly for one-time events or to implement a kind of mini-boss without having to create a separate actor every time. Aside from this application, even DnD5 itself has such a feature as it allows for monster hp to be rolled individually for every monster instead of using average values.

[tposney]

I finally heard back from Atropos regarding the origin "problem". In 0.8.x (where x is probably 1) this will be resolved and the origin will point to the correct item, even if it came from a token (as compared to an actor).

[tposney]

In GitLab by @marcoseither on Feb 28, 2021, 23:50

Thought so - as far as I understood his announcement posting, 0.8.X does a major overhaul of the core data model and improves support for unlinked tokens a lot. Looking forward to see this in action.