[Discussion] Modal power handling

[FoxLee]

I was tinkering with this a while ago, but I got caught up with other stuff and I'll probably have to restart since the system has been updated a lot. But basically, I want to implement a handler for modal powers! Stuff like augmentable, full discipline, hopefully even ranged-or-melee and choose-an-element type powers. The 5e parts of the system seem to contain the remnants of this sort of thing—presumably for 5e's horrible cast-at-level-x spell system—so I was essentially trying to resurrect that in the power use dialogue.

My idea at the start was to allow powers a "modes" array. So you would build the power with default values, then create an additional "mode" for each usage option. Each mode would contain an arbitrary number of key/value pairs with the id for the field that needs changing, and the new value to assign. The power use dialogue would then allow you to select a mode, and substitute the associated fields in the data it sends to chat/processing.

Recently I had a second idea, which may well be easier to implement, but I'm less sure of how to do it; could each "mode" just reference another power? So you could create each option as a separate power with its pre-set values and cost (or, say, use a handy dandy importer that already handles them as such) and add them all to a single "parent" power that hides the child powers from the sheet, activates the modal dialogue on use. It sounds good—and like it would create the easiest transition from the current situation—but I've never dug that far into Foundry's object modelling. I wouldn't be surprised if allowing powers to contain other powers is straight-up impossible, or at the very least would break variable and effect handling.

What do you folks think? Am I on the right track with either of these? Does the second idea create some untold recursive nightmare further down the line? I'm eager to start digging into this again, but I need to make sure I know which direction I'm headed first :}

[EndlesNights]

I might like the idea of items containing sub items as it's in a similar vain as two other goals. I recently have been tinkering around with reworking container items (so they can contain sub items) along with another concept of an "ItemGranter" element that I would like to attached to all item objects. The primary function of an "ItemGranter" would be so features and magic items could contain an number of sub items that could be dynamically added or removed from a character while only having to manage the item. (ie a magic item that have the use of powers)

One of the updates to the data models of Foundry v11 better support EmbeddedCollection of document types, which we've already started to use with how we can no better manage activeEffects that come directly from items while on a Actor.

[FoxLee]

Oh hell yeah, I never thought about it in terms of global application! That sounds ideal if we can get it. Even with the relatively small amount of material I've added, there are so many items that want to be "bundled" together, I can see that making a huge difference.

In light if that, I won't bother resuming my tinkering with it right now—no point repeating the same work, and you definitely have a better understanding of the groundwork than I do. But consider me very excited for the possibility :D

[EndlesNights]

Minor hiccup, it turns out we can not insatiate new EmbeddedCollection outside of what the core software already does. Looking at how the 5e team has handled Containers, and their own Advancement system, they merely store references to the location of other items.

[FoxLee]

I was just looking at the new 5e stuff yesterday. Dang they seem to have gotten a lot of exciting new stuff. Still seems to be open-source though, so hopefully we can incorporate most of it? There's probably value in following their implementation anyway, since then we're can keep piggybacking on modules made to support 5e :p

[EndlesNights]

I have a rough prototype for Item Containers working based off of what the 5e team has done. It still needs a bit more work but I will push it to the dev branch tonight or tomorrow. I'll still have to redraft what I had wanted to do with item granters, while item documents could still be stored in a serialized array, they wouldn't be easily editable. The 5e Advancements Documents might not be what I had in mind, but could still be workable.

[FoxLee]

I finally had the chance to check this out, and it looks very exciting! It's even correctly applying things like features from within a container, which I was not expecting to work right from jump. Will it really not work as a model for for "item granters"? It feels like it's so close, such a shame if it's a dead end :\

(Not that having usable bags isn't great! It's excellent, of course. I'm just itching to bundle my augmentables of course :p)

I noticed that, at the moment, I can't load the container with items before adding it to a character sheet; everything inside just vanishes. I'm not sure if that's a bug, or just a limitation of the code? It would be real handy to make containers pre-loadable, for stuff like adventurer's kits or treasure bundles or whatever, but I get if that's not possible within the current infrastructure. Indeed, if that's the case, that may be the detail I'm overlooking when thinking about item types like classfeats?

Would it be a good idea to show the contained items in the inventory list? I feel like the most convenient for a physical bag would be to have contents hidden by default, but visible when the container is expanded in the list. But if we went on to use this model for other item types, it probably depends on the container—like, for a class or race I would definitely want it to show them all, but for modal powers I imagine you would want them hidden.

[EndlesNights]

I noticed that, at the moment, I can't load the container with items before adding it to a character sheet; everything inside just vanishes. I'm not sure if that's a bug, or just a limitation of the code?

That is how it is suppose to work. There was a small bug that was breaking the interaction. It should now be working as intended.

The basic principle of this can be used for a bases of an "ItemGranters" class I suppose, it just don't quite match the initial idea of embedded item documents inside of other item documents, but rather uses a smoke n mirrors to hide certain items in the actor-inventory / world-directory. If you try to export a contain item as JSON, you may notice that there is a distinct lack of its content items.

[FoxLee]

I noticed that, at the moment, I can't load the container with items before adding it to a character sheet; everything inside just vanishes. I'm not sure if that's a bug, or just a limitation of the code?

That is how it is suppose to work. There was a small bug that was breaking the interaction. It should now be working as intended.

Ah brill! I thought that was probably the intent :}

The basic principle of this can be used for a bases of an "ItemGranters" class I suppose, it just don't quite match the initial idea of embedded item documents inside of other item documents, but rather uses a smoke n mirrors to hide certain items in the actor-inventory / world-directory. If you try to export a contain item as JSON, you may notice that there is a distinct lack of its content items.

Honestly, I think this might actually be better for what I was imagining. Like, if all the items are actually added to the actor, and it's just a question of messing with how they are displayed, that gives us a huge amount of flexibility in how it's handled. (That's assuming I understand it correctly—but it seems to be the case, since the actor export does contain all the data.) Unless something prevents using the container item to find the contained items, my concept for modal powers should work well with this.

Perfect for adapting display based on different foundry!item types, too! One could do it with pure CSS even, which will be a blessing when I get my alternate character sheet built :D

Maybe it's just because my background is specifically in frontend development, but "the data is in a big pile, manipulate the visuals to suit your purposes" is always the best case scenario for me :p

[FoxLee]

@EndlesNights Assuming you are okay with using this behaviour for other foundry!item types—should I assume that's on my plate, as I'm the one itching to do modal powers and such? Or do you intend to work on it yourself? I'm certainly eager to get into it, but I don't want to get in your way or anything <XD If it is my task, I assume it would be best to wait until container bags go to live release before I start working on the same files.