SidebarControl musings
I got very intrigued by FVTTSidebarControl and it calls to me to make PF2e Graphics basically have its own sidebar for displaying stored animations.
I'd even indulge in that calling but do you have any ideas on how to make such a thing work without an actual collection to save all of it in? I thought of maybe some kind of derived store that takes in all user flags and world setting but that sounds... inefficient.
44 Replies
Is this writable only by GM level users, but usable by all?
GMs can add and edit global animations
Users can also create animations, but are scoped specific to what they have access to (storing in user flags, on actor, or on item)
Not exactly worried about displaying the last two in a sidebar, though it would be easier if I could simply reference them when I think about it, instead of storing entire massive json objects in flags.
"A-A on steroids" continues to be an appropriate comparison to default on if anything
AA currently uses WorldSettingArrayStore. This isn't terribly efficient as it basically serializes everything on any change. It also is only writable by GMs.
Also raw JSON storage. It might be nice in the future to include options for custom serialization like incorporating the MsgPack compression functions.
Yeah, and PF2e Graphics currently is storing everything in flags + world settings (and the windows for editing it continue to somehow propagate data between different documents at times, which is very annoying).
There is this issue https://github.com/foundryvtt/foundryvtt/issues/5455 that will not come anytime soon, but food for thought
GitHub
Proposal: Basic Document · Issue #5455 · foundryvtt/foundryvtt
From the League: Basic Document Introduce a new document type, BasicDocument which implements Document along with a BasicDocumentData which implements DocumentData. The new BasicDocument would funt...
I'm aware of that proposal, but not likely anytime soon especially with Ember and all of that upcoming. I don't see the core team working on the platform except for features they deem necessary for Ember.
Yeah yeah
Either case, reworking the UI at the moment and it makes me wonder about alternative storage methods
Kind of going to be the repeating theme / reminder for the next couple of years.. ;P
It's a problem regardless if you create a sidebar.
I know
But the sidebar prompted me into thinking of it lol
Before that I was considering scrapping my object-based approach and just do everything in arrays as well
Because for all the problems of constant serialization, you cannot fuck it up
and flags are notoriously hard to remove properties from, which makes iterating over keys very difficult
You basically have to diff everything due to how
update works and then append - to anything removedI guess that is the nice thing about
WorldSettingArrayStore is that it has some structure to the serialization that takes it out of the hands of the end developer, uh, fucking it up.🥴
It's an area that needs to be revisted as well.
WorldSettingArrayStore was kind of built for AA, but not really investigated much / 2nd pass since then. Also of course store based vs maybe something that can be improved with Svelte 5.runes certainly give a lot to think about, and makes this kind of reactivity a lot more explicit and easier to understand
re: whatever the hell is happening with <1.0 PF2e Graphics windows saving an animation in an item causing it to duplicate to world settings if both are open, sometimes
Either case, sidebar definitely fits the M.O. of how I store animations, its basically a Map of
primary-triggering-roll-option: { animationData }
roll-options being basically tags attached to every action, template, or roll you take and do in PF2eYeah, I don't really have much of an internal vantage point for AA or what you are cooking up. I'm not a user of either. AA side of things is basic at best just in trying to help keep it alive.
Very cool on that
dimensional step animation. Does it limit the distance of the teleport.. I gather not.It can :p
Its all Sequencer still
We are just making a JSON abstraction layer for it
And now I am gonna make an UI for that
In the back of my head I do eventually want to run a short campaign and someone wants to play an Echo Knight, so I'd have to muck around with something to make that happen.
Work on TRL has prevented any of that, so... not happening anytime soon.
I don't really have a good idea / solution outside of world setting serialization. That can definitely be improved. If you are eventually getting things into a Map though it's worth noting that with the MsgPack serialization you can directly serialize Maps, Sets and more instead of converting everything to arrays / normal JSON serialization.
oo, looks interesting
I see it is included in the #runtime module, any pointers on using it?
These are functions that I created that combine MsgPack, compression, and optionally converting to a base 64 string. The
B64 ending functions do the final base 64 conversion. This allows you to store / retrieve complex data structures that are serialized as a string. You can store a string somewhere in Foundry.
Granted a bit potentially dubious because if by chance something went wrong you'd potentially lose the whole data structure. Chances of that happening.. probably low, but it is what it is..
I don't have any example in Foundry or the demo code that uses these functions, but I do use them for my TypeDoc theme. I serialize all of the data used in the Svelte components in a single compressed data file which is loaded on the client side. This includes everything from the search indexes to the navigation data / tree of all source files. It seems to work well.
---
On the offside of the compressed B64 string becoming corrupted perhaps one can save an alternate as a backup every so often. Just a basic precautionary concern that might not even be a real concern in practice.
I'm just thinking that it would suck for someone to create a ton of animations then have something go wrong. Not likely, but no easy way to undo any damage whereas raw JSON data can at least be examined.Yeah, I am wary about that aspect. Curious, but probably not gonna do it.
Maybe will do it for the premade ones though on build time.
Actually, no, they are loaded in a non-blocking way anyway.
A lot of the pain in doing novel complex things really just comes down to the inflexibility of the Foundry DB model.
would also suck to debug
sure sounds like it
Still, the sidebar gives me ideas on how to at least make it Look Good™️
backend be damned, undertale was a thousand if statements
(not really damned, I like my backends, but I am not gonna live and die by them)
Yeah.. The sidebar support is something I hopefully can get working on v13 as well. It's why I added a demo to
essential-svelte-esm to remind me that it needs to get done. Also didn't hurt "some exposure" for the feature.I'll definitely go and look at that one
I gotta update my local one anyway
Oh things are not great on v13 right now... It's definitely going to take an effort and fingers crossed I can make it smooth for end devs using TRL.
🫂
Oh great JournalEntries are gonna be fucked soon
Forgot that one was coming over to AppV2
Big problem is that v13 uses AppV2 for sidebar apps. Um.. Well AppV1 / SvelteApplication still has a
render and close method w/ same signature.. There are several unknowns presently.
It'll probably work.. There is a little bit of faking things in the current implementation of the sidebar control, but well there is faking things on the Foundry front for a lot of things like TJSDocument too; about the same kind of "fooling" Foundry going on..
Here is where a fake sidebar app is added to global data..pff
yeah, pretty sure I did a similar thing for Vauxs' Archives and its modified version of the chat log
I really wish I could have a short chat with the core team and hammer out some of this stuff. Make things more resilient, but things haven't broken either. Chances are they won't change how the sidebar works after v13.
Also they haven't changed between AppV1 / V2 the really weak and hard association registering of apps with the ClientDocumentMixin thing. That is not a good implementation from the get go of Foundry and would be something that can be drastically improved upon if documents could just be subscribable.
You don't have to get rid of the old way and can also add a new way that is better, but such is life.
Back on topic
I'm working on adding / verifying a bunch more TS stuff. Do you have
strict: true in your tsconfig set?Yes
I basically fixed that already. Likely needs:
class: new(options: ComponentConstructorOptions<ComponentProps<Component>>) => Component;Do note that
strict is also what comes with the svelte's included tsconfig
TJSSvelteConfig uses generics now and also a lot of other type hookup with SvelteApplication. Hopefully I get this out soon.
Does it compile with
strict: false?
If so use that until the next update.It compiles with strict either way
I'm generally aware of this and what I'm working on should fix it.
Might want to be careful in general I assume you import a class Sidebar as there is a global
Sidebar that will be defined in Foundry types.
Yep.. I can confirm that my change to TJSSvelteConfig will fix this issue in next.7I do have a suggestion to add
classes to the sidebar options
If you want to reuse system styles, you have to add this after the add
This also doesn't work with the popout now I look at itGet your filthy JQuery out of here.. ;P /s
Filthy because its done quick lol
Just to check though.. You can't add that in the Svelte component being mounted?
I was trying to perfectly replicate the DOM in case there were any selector problems, but I will look it up now
yeaaah there is a bit
specifically
directory flexcol
It has to be in the top element in order to allow scrolling
Or even more specifically, you need a way to add overflow-hidden to the sidebar
like, in general, if you want to make much use of it
Making a list in the essential demo makes for an overflowing sidebar, and because the underlying child element just stretches, you cannot put an overflow limiter on itFor consistency probably best to add it. Will be in the next update.