23 Replies
I got roped into this and I shall now rope you into it
Most excellent.. I think @frondeus will be along shortly. 😄
Of course 🙂
It's definitely an interesting situation particularly w/ the lack of ongoing community types support that adds a potential bit of extra pinch to forward oriented maintenance with what you have created.
Yeah, my codebase needs a solid refactor, thats for sure. I also managed to abuse
$: operator quite a lot and that is very powerful yet very dangerous tool 😄
The reactivity one in Svelte
Professionally im more a backend developer than a frontend guy : )
So coming from Rust world, types sounded like a good idea back then when I started working on this moduleOh woe those who use TypeScript inside a non-TS environment
Absolutely. I haven't taken too in depth of a look at the codebase, but did see several things that can benefit from using TRL / my UI framework. There is a solid bridge to mounting Svelte components / controlling the app lifecycle vs adhoc mounting in
activateListeners. Many other cool things as well as in TRL the entire "application shell" is Svelte based and out of the box HMR is supported w/ Vite, so a more pleasant and instantaneous dev loop is possible w/ Svelte on Foundry.
Another possible thing to look out for which can happen quite easily is "prop drilling" where you pass around props from the top to bottom components. You'll find that in a fair amount of 3rd party Svelte components and is an easy thing to do when you first start using Svelte. This kind of "anti-pattern" affects Vue / React too. I'd have to look at the codebase in more detail though to see if that is present.
I do create types for TRL and the next release upcoming soon really strengthens that a lot, but the missing bridge to Foundry still remains.TRL looks interesting 🙂
Svelte is a great tech to choose for Foundry dev IMHO for many of the reasons that you mention in the Syrinscape forum post. It just will be a bit harder to find folks that can help contribute that also are active in the Foundry 3rd party dev scene. I'm lucky to be able to work on dev efforts full time right now, but am pulling back for the time being on direct package dev spending all of my time on the UI framework. I justify all this work as I'm expanding the UI framework / desktop app like UI toolkit beyond Foundry to reach the entire Svelte dev community. Foundry has been a great environment to move all that forward.
I have been working on TRL full time+ since Oct '21, so it is well onto the path to maturity. Don't mind the "alpha semver" as I am rather conservative on that front. I'm considering things reaching "beta" when I have everything fully working on top of SvelteKit / open Svelte dev & Foundry. The general expectation that this will be reached first half of next year. TRL has been rock solid though on Foundry for quite some time.
Re: Typescript and how to move forward w/ the SyrinControl codebase. It probably makes sense to convert to ES Modules / ESM. The nice thing is that there is reasonable intellisense support in various IDEs for Foundry. Some are easier to setup than others. WebStorm for instance is straightforward and reliable. Using JSDoc + types in comments is a viable way forward for type safety.
For library / framework efforts like TRL I have developed tooling to generate TS declarations from ESM + JSDoc source code that works well. This is how I ship types for TRL and am generating API docs. The next release that is incoming shortly finally provides comprehensive API docs which is nice.
For an end package like SyrinControl JSDoc does work out nicely when you hook up the IDE to the underlying JSDoc types in Foundry.
All the type information that you have in Typescript will transition to JSDoc /
@param tags.I agree, probably JSDoc would fit better than TS. However that means complete rewrite since I used TSysinge - microsoft's dependency injection framework for typescript. I tried to separate logic from UI and from API calls for better unit testing 🙂 Of course I bet there is cleaner alternative to that problem.
Anyway, I looked at the TRS example anc I like what I see. It is more focused on the dialog windows, am I correct?
TRL does cover quite a bit of territory, but does have strong support for complete Svelte based control of the app windows that is more efficient than core in performance and capabilities. IE you can do full matrix transforms on app windows.
Re: tsyringe. It does look like the dependency injection usage is mainly for your
game wrapper FVTTGame which all of that can go away in an ESM version as you can just access game directly without the fuss of the strict version of the community types.
I think you should definitely wait until I get the next TRL release out especially since it comes w/ API docs. Hopefully ~2 weeks or less for that.
It's no small amount of work though converting what you have to ESM.
This is a good recent article discussing JSDoc and TS integration: https://dev.to/samuel-braun/boost-your-javascript-with-jsdoc-typing-3hb3
You'll probably hear me mention import types and this is something modern IDEs allow in JSDoc via TS (also worth reviewing the rest of this page): https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#import-types
For anything that you can't conveniently type in JSDoc you can create a d.ts file and reference via import types.Wow! Just so you know I’ve no idea what you’re all talking about but it looks impressive!
I’m glad that you’ve got a dialogue though.
I’m back from holiday/vacation tonight so I’m going to contact Syrinscape just to touch on the point of financing something in their interest.
Hello there folks,
@frondeus @vauxs @mleahy
It is with great sadness, that Syrinscape have written back to me and told me that they are not going to fund anything Foundry related and that it is up to folk to create their own modules to integrate with them.
Another person on the forums has suggested paying a patron account for Frodeus and anyone who is helping them. I said that this would be in effect paying twice for Syrinscape when other sound providers are either free or you can add what they have got via core.
It baffles me that Syrinscape said themselves that they met "lots" of people wanting the integration at conventions, and if they were to invest they would get more subscribers, yet won't commit to one of the most popular VTTs out there.
I think due to this I am going to stop subbing Syrinscape and use a different method. Wavs and Oggs and Mp3s etc....
I am really sad about this, as I have been loyal to Syrinscape for so long now. 😦
Recently I got a contribution to the Syrin Control and the guy was pleased with the codebase he found 😊
He might contribute in the future but that's it
About the funding - I don't think patron account is not the solution. Sure it would be nice to get money from it but the point is - I won't be able to pay the bills and live only from the Patronite with the current playerbase
Which means I of course won't quit my job
And the problem is not money but time
If Syrinscrpe does not want to invest in it then so be it
I'm putting the effort in the project only when it's beneficial to my own campaign
And the problem is not money but timeTime is money as things go, but also important for sanities sake if you are a working professional. If you are a pro / solid developer you already know what your time / hourly rate / worth is as well. It is very hard to balance passion for a space like TTRPG in respect to VTTs. VTTs already are a niche of a niche and making plugins / integrations to a single VTT is
niche^3, so not a profitable or easy thing to be involved with as there is a lopsided value proposition that flows upward to the platform and services one integrates. In other words the maxim "the platform always wins" is playing out here.
I have the same general problem in respect to Foundry itself as while the Foundry team has courted content creators they have completely ignored setting up a well functioning store that could provide a possibility for sustainability for the 3rd party development community. No one is going to get rich making plugins for a VTT. I've given Foundry several years now to get their act together and wide leeway given the indie start, but they have over 10 employees now and albeit still a small company. At some point it's just negligence and while maybe not a "corporate sort of greed" still is a non-starter for continuing to send value upward with little in return.
So, basically I definitely understand the sentiment and situation. I don't think Patreon is a good mechanism to fund high quality software development either. It's a nice alternative to throw a little extra cash to a creator you like, but a poor solution for software in general.
I very much consider that for a platform to be truly successful it needs to provide more value than it captures for all parties involved and we are not seeing that in the TTRPG / VTT space.Yeah I saw that... I held back from writing a post there warning the future "poor soul" that is being misled about what is a real work job. Syrinscape had every opportunity to minimally support the previous dev financially, but chose not to.
System / API integration between two platforms along with maintenance is a a job and one that requires adequate compensation.
Checked their forums, their top non-pinned post is about Foundry V12 and they literally said 15 days ago, they dont have capacity for that
So thats funny
Join the Fun at the Syrinscape Forum | Syrinscape
SyrinScape for Foundry V12+
Hey all, Yes, it’s sad that @frondeus is not able to keep support on this one. Their hard work was GREATLY appreciated by us here! 🍕 🍻 🥳 It is possible that all SyrinControl needs is a check and update of compatible version counter. Taking over OURSELVES is not something we have the capacity to do right now = there is SO much important stuff ...
make up your mind! 😆
but it certainly looks like they jumped the moment people talked about unsubbing because of this
They are a commecial company that charges a premium for what is a lackluster IMHO service. They have the money if there is will to support this integration.
This is also going to be an engagement where you'll be requested to take over an existing codebase. Frondeus did good work, but taking over an existing codebase also turns out to be... real work..
Not that I am planning to take it, I recently bought a bunch of SFX humble bundles 😂
I have 60k audio files
I dont need a D&D-centric spotify
The thing that cracks me up is that if I gave my minmal hourly contract rate from 15 years ago (granted SF Bay Area contract rates) that this would be denied / rejected by most TTRPG / VTT space companies today. My inflation adjusted current rate is well beyond this now.
It just sucks so much regarding this "community development" mythos surrounding 3rd party development in the Foundry scene and beyond. I personally think this mindset and engagement angle from Foundry is highly damaging to Foundry in the long run. There isn't an unlimited amount of knowledgeable devs that can do good work and are passionate about the TTRPG / VTT space; many have already left the Foundry / VTT space.
On my side this upcoming FQL release is my last and I'm passing the torch back to Forien to move it forward. I can't justify the cost on my side at all supporting it. I estimated that the full switch to AppV2 for FQL would cost me ~8-10k USD minimum in raw cost of living time on top of the 6+ month full time / ~36k USD I've already committed.
I should note that I'm still 100% focused on TRL and moving that forward and I'm simply minimizing other outside commitments like FQL to prevent future context switches and regressive uses of my time.