[Feature Request] Add the ability to add a macro as a result of the recipe to be launched

[p4535992]

Thanks to the hook created by you "beavers-crafting.processed", I can manage my use cases, but I force too many people to go through me for the integration of their stuff and I got this idea and if we allow to add as result not only the a resulting item, but directly a macro ?

Let me explain better when the crafting reaches 100%, instead of creating the item on the actor we launch a macro with the arguments "actor", "recipe", "result", "processed" valued, leaving the update of the actor to the macro (similar to the item piles solution https://github.com/fantasycalendar/FoundryVTT-ItemPiles/blob/46295cb0850c1b559ab773dd030f558315167e86/src/helpers/utilities.js#L337).

With this solution I could at that point handle any use case without bothering you further, I also think it is a useful solution for any system not just Dnd5e.

From a code point of view it seems feasible to me what do you think ?

If it is something you would be willing to consider I can try to do a PR.

[AngryBeaver]

I do not feel that this is a good idea.
a) if the macro is creating items my code is not allowed to -> so either everyone needs to define a macro or nothing will happen.
b) if macros have to create items the macro would need insight into my code and needs to be updated everytime i would consider an update ? e.g. latly deside how and when to stack items and when not (isSame) and set flags when apropirate (created flags etc..) -> zero control.
c) i would need to split up returning unsconsumed costs and creating results or even worse also let the macro return costs. which i can not guarantee that everyone will implement it. Especially people with less coding knowledege
'
leaving the module crippled and unusefull.

[p4535992]

I am not sure if these problems (although valid I will try to look at the code better if there is a "smarter" solution) should be taken into account, i.e. if one puts a macro type object as a recipe result the "responsibility" of the result is only of the person who created and used the macro.

Starting from the fact that I look at your code a little bit better, I will highlight my thoughts on your doubts.

a) if the macro is creating items my code is not allowed to -> so either everyone needs to define a macro or nothing will happen.

if the macro is creating items my code is not allowed to

It's not your responsibility, you just give the ability to run a macro as a result, I don't think anyone can blame your module for this.

so either everyone needs to define a macro or nothing will happen

It is not your responsibility, in my specific case I just wanted to create a scroll spell starting from a spell component using the "anyOf" feature, in this case the macro (or the module api I want to use) uses items present in the actor, but again do you care what i want to do ?
Also you can avoid to "everyone needs to define a macro", with other modules api or a specific custom code

The only thing your module could do is the item piles trick to give permissions on the macro created by the gm to have the player launch it with his permissions etc.

macro = new Macro(findMacro?.toObject());
macro.ownership.default = CONST.DOCUMENT_PERMISSION_LEVELS.OWNER;

b) if macros have to create items the macro would need insight into my code and needs to be updated everytime i would consider an update ? e.g. latly deside how and when to stack items and when not (isSame) and set flags when apropirate (created flags etc..) -> zero control.

if macros have to create items the macro would need insight into my code and needs to be updated everytime i would consider an update

No way it's not your responsibility! you just give the ability to run a macro with some argument "actor", "recipe", "result", "processed".
Do you decide for example to change the name of the arguments on the module ? or some data structure ? it is my problem not yours !

c) i would need to split up returning unsconsumed costs and creating results or even worse also let the macro return costs. which i can not guarantee that everyone will implement it. Especially people with less coding knowledege

okay I got a little lost with this point, but I think the answer is always, it's not your problem.
You only run the macro at 100% completion, the rest has to be handled by the person who prepares and develops the macro no ?

I don't think anyone can blame your module for this, when you reach 100% you simply run the macro instead of performing the update on the actor, the consumption code of the components remains the same no ? isn't it ? it will have to be taken into account by those who develop the macro.