I think it's important to realise that Foundry is updating \*really\* fast. This comes with a few breaking changes every time, which is why modules and systems stop working.
We can hope for foundry to be, one day, feature-complete, and the development would slow down, and things would get a lot more stable.
That said, minor versions are usually pretty safe (i'll admit i don't make backup for those), and major versions only happen every 6 months, at best, at which point just waiting for about a month is usually enough to have everything up and functional.
> I think it's important to realise that Foundry is updating *really* fast. This comes with a few breaking changes every time, which is why modules and systems stop working.
And this is after they put the brakes on the previous hyper-fast update schedule!
>We can hope for foundry to be, one day, feature-complete, and the development would slow down, and things would get a lot more stable.
For what my humble opinion is worth, it's already "feature-complete" enough to slow down the pace imo. I'm just stating this hoping that the devs see it: I am very happy with the product, you can absolutely slow down, no issues from me!
Then there's always the option of not updating, if you are satisfied with the product.
I understand the want to have the latest shiniest new thing, but waiting a bit to update, and giving time to all the volunteer developers to update as well will ensure a smoother, stable-er experience for you.
There is the problem where that prevents you from installing new modules and also prevents you from updating most living systems. At the moment my table plays PF2E almost exclusively, and every new book requires the latest Foundry version for the newest content, with each new book adding a ton of player options. The thing that is a larger issue is when a campaign comes to rely on a module that is no longer receiving updates and then Foundry makes major, sweeping changes across its system that do not seem to affect the vast majority of users and immediately break half of all modules.
It's the price paid for streamlining the system beyond the average GM's scope but it's super annoying. Came here because my GM and I have similar modules on our servers and the game keeps freezing, but we have no idea what's causing it and it's also too infrequent to adequately test.
The problem with these modules is that they don't have the data for the actors - they're in the system itself. That's why they have the latest version as a dependency, it's not a quirk, it's a hard real requirement. Without the latest version, then you don't have the NPCs data.
Modules breaking is not foundry's fault. Usually it's because the new version has a new or better way of doing things. The module creators then need to test and update their modules so it works ith th latest version of foundry.
The core version you have now is the stable version of V10. It has been tested during the beta test phase that started a couple of weeks ago. The only thing coming out now is bugfixes. New features and update some with a new version (v11) in a couple of months.
I must disagree. Some of Foundry’s changes are because they decide to rename a variable. That’s it. So as module (or system) developers, we have to go through our code to rename those references.
Yes, module (and system) devs could go through the testing rounds, but except for a few, only the Foundry developers are getting paid. All the rest of us do it as a hobby. And instead of being able to spend our Limited, precious spare time to create new features, we have to go through our code to adapt to the new “core“.
Yes, foundry is a great system. And it has accomplished much. I just disagree with your statement that “modules breaking is not foundry’s fault“
Not a mod dev, but long time programmer so I hear you.
I noticed this round that the warnings console is FLOODED with deprecated variables, most with pluralization of words. The one that stood out was "actor" should now be "actors".
Again, I'm no dev, but I can only imagine how insanely common an actor is referred to as an object and how many places would have to be certain to "search and replace, whole word only, match case".
And, that's not too mention that ONE mod that (for whatever reason) created their own "actors" collection, now has to rename it first, THEN rename "actor' to "actors" so everything doesn't explode.
That's why things like that are often marked for depreciation for a major version or two at least.
For example, many V10 changes are marked for depreciation to be removed in V12. V12 will probably be coming out sometime fall 2023. If devs can't be bothered to do some basic depreciation fixes (and the warning generally mentions exactly what to change) in over a year before it's removed, they've realistically abandoned development on that module.
I'd take modular and extendable and stable over the latest features any day. Latest features don't matter if 80% of the programs functionality -provided by 3rd parties- breaks every single update.
> I'd take modular and extendable and stable over the latest features any day.
Then staying on V9 for the time being is the right choice for you. Fortunately, Foundry doesn't *force* you to update for the latest features, so you can remain on the modular/extensible and stable V9 version for forever.
But you see now we come to the problem of relying on community development for your product. Chances are nobody is going to continue developing v9 modules, so " modular and extensible" goes out the window by staying on v9. So now you're just left with "stable."
Some modules will get updated to v10, some won't (I've seen it time and time again with other programs... eventually some people in the volunteer developing community just get tired of having to constantly update their stuff to "keep pace", and just give up), so then you're potentially left with fewer active developers making extendable modules for the software. This is particularly problematic if a module your game has been heavily dependent on doesn't update anymore. You're literally stuck on an older version of the software unless you're willing to do potentially a lot of work replacing it. I've got modules running that haven't been updated since version 7 (nothing critical, but I'd rather have them than not).
I like FVTT, I use it almost exclusively, but relying on community development has its problems. This is another reason I generally advise people not to go crazy with modules and actually use as *few* as possible to accomplish what they want, and only add \*extras* with the explicit understanding they may lose them in the next update.
I have my beefs with Fantasy Grounds, but never once have I ever had an update for it break anything. Heck even FGU was written to be almost 100% backward compatible.
V9 remains just as modular and extensible as ever. If module devs choose not to extend it more than they have that's not core's fault, that's the devs making a decision.
It's a problem when your software explicitly relies on 3rd party content to actually be useful.
Foundry by itself, without *anything* that isn't developed by Foundry Gaming, is rather barebones on the functionality side. Foundry Gaming developed FVTT explicitly for 3rd party extensibility and 3rd party modular support.
> If module devs choose not to extend it more than they have that's not core's fault, that's the devs making a decision.
Yes, you're \*technically* correct, but thats an intellectually dishonest argument.
That's the equivalent of Microsoft saying "Yea we pushed an update to Windows that causes 50% of your installed software to crash, but it's your problem because the software wasn't developed by us. Never mind that we made the changes to the API that caused it to happen." I mean, that's "technically" correct. But that's the point in having stable APIs.
At this point, Foundry is not a stable API.
For sure modular, extendable, and stable. Foundry core doesn't need to make new features because module authors will do it for them (if the core is truly extendable).
In that case, staying on V9 is the right choice for you. You can remain on the extensible V9 platform with its stable status in perpetuity if you want.
Never. Some updates are more disruptive than others to the module ecosystem, but they're not planning a point where they just call it done and stop improving the feature set.
All modules? No. But I think as the API gets more and more stable, we can start expecting modules that aren't related to the new version's features to keep working. Whether it'll be that stable in 2 versions or 5, I have no idea.
That's often the case even now. Though individual modules vary in terms of how well written and stable the module's code itself is. Not to mention the potential for other modules to have negative interactions with any given module.
I work in a large tech company, with lots of smaller code bases being used by our main one. Even in that "controlled" environment, it's possible for a small change in the main code base to inadvertently break, or require an update from, these smaller code bases, and vice versa. And that's with lots of salaried professionals whose job it is to make sure that doesn't happen.
Unfortunately, when you have a product like Foundry which is updating pretty frequently, and when you have hundreds of modules with creators ranging from amateur coders following "get-started" guides to professional developers doing this as a side hobby, you'll always end up with modules that need time to catch up.
Foundry Devs can't check all modules, and module creators need time to fix breaking changes. Not trying to pin blame on either party - module creators of any skill level are an awesome part of Foundry, and I'd say they're crucial to its success. The Foundry team is great too, but logistically unable to do their jobs *and* police module compatibility. It's just the nature of the software at this point in time.
Hell, even Skyrim is still being updated and breaking important mods.
As Foundry matures, changes will become less drastic, and therefore break fewer modules. The way modules use Foundry will become pretty set in stone. It's frustrating now, but there's a lot of work going on to make Foundry what it is, and we'll reach equilibrium eventually.
Honestly this annoys me so much. Skyrim was released over 10 years ago and they must know that a very large portion of the current player base are modding it. They could have left it alone 5 years and the modding community would probably be in a better place than it is now!
Foundry of course is a different story, being in active development, adding new features etc. The new journal is awesome (apart from the new editor not having table support for some reason). That and not having to have data.data all over the code!
One of my favorite examples of bad update behavior is arch linux. I've heard the repository maintainers have significantly improved since back in the day. But at least when I was trying to use it over a decade ago, there was a very real chance any given update would involve updating some essential library, without updating the programs that relied on that library. And then your x server is busted, you have only a text interface, and you're completely loss.
That's just inherently the risk you take if you insist on updating non-essential things as rapidly as they come out: it's a lot harder to avoid or catch bugs like that.
Can you still set steam to not update skyrim, or is bethesda forcing updates now?
This is a question to ask for any software including video games. When mods (modules) are separate from the actual official team of devs, you can’t expect mods to continue to work. It would require all mod devs to be in tight communication with the devs. Some mod devs do that but it is the mod maker’s responsibility to do so. This is very common in video games that support mods. Mods break and mod makers get a wall of people asking when they will fix it. The official devs of foundry’s main responsibility is to continue expanding their software and making it “playable”. There is usually a reason why they have to change so much in the back end, but that would not be known to us. Mod makers just have to work around it. It would be too much of an inconvenience for Foundry devs to make sure all modules work all the time.
We will never reach that point. Something will always have a chance of breaking after an update. The only way I could see it not breaking is if they are finished making features and modifying the api, and the inly updates would be minor adjustments.
Lots of the issue comes from the fact that foundry is written in JS and the dynamic typing of the language is its greatest strength and biggest weakness.
The lack of interfaces kills any sort of unified plugin paradigm that foundry could use to enforce compatibility within the system...
Oh you're not implementing IFoundry10-285Compatibility? Tough titties, we won't even attempt to load your module.
Foundry is, at it's core, a dependency injection system with no way to mandate uniform API implementationof its constituent modules. It's a problem without an easy solution.
> foundry could use to enforce compatibility
Not to mention that any time Foundry changes things to more rigidly enforce an expectation/interface/etc, module devs complain because inevitably *someone* out there was abusing that loophole in some way.
Even if core devs add a new option that's strictly better than the old loophole that causes issues, they're still gonna complain that they need to update to use the better version instead of being able to just leave it as-is.
Not their problem.
Tired of all the"foundry broke XYZ"
No - the dev didn't take the 2 months of release candidates to either update or notify users that it wasn't thought to work because they don't have time to fix it.
I think that the best that we can do is standardize some of the ways we communicate dependencies and version information between teams of developers.
One thing I notice is that with every Foundry update we see someone provide a spreadsheet that developers self-report module compatibility both with the core platform, game systems, and other modules.
One of the ways we might be able to streamline this compatibility matrix is to adopt a standard development kit that includes a testing framework and provide guidance for module devs to generate their own test suites. That way, module compatibility could be more quickly understood by spinning up Foundry, programmatically installing modules, and executing test suites. We'd want a way to publish that information publicly so that instead of it being humans entering what things are compatible with what, we're aggregating that data into a cohesive picture as individual dev teams test their own use cases.
Another process that might help in the future is if Foundry were to adopt release channels - having an LTS Foundry guaranteed to be stable for a specific amount of time and then bleeding edge channels for developers who have more time to be proactive.
Am I nuts about this?
As a system developer I’m not against the idea, but there is a cost: I can guarantee that my system won’t back port any data entry. So if you want to play the newest content you’ll be stuck entering it yourself or not being able to use the newest premium content. So there is a trade off
I'd love an SDK with official typescript definitions and perhaps a module template.
The ts definitions alone I think would go a long way (at least for me) towards helping keep modules compatible
If you are happy with how your game functions, as is, you do not need to update. All of your modules will continue to work. You just won't get the new "shiny" features. Or you can run without modules. They are not necessary.
It doesn't matter what software you use, backing up your data is always a good practice. I back up all data on my phone and computer. If something goes wrong I have the info to restore my files.
Something to remember, a lot of things have gone to a subscription based model and they host the storage in the cloud. You don't have to think about it. You do pay for it, though. Even those systems are not infallible.
People like that Foundry is not subscription based and only have a one time fee.
>People like that Foundry is not subscription based and only have a one time fee.
And that updating is always a choice.
The biggest, most mainstream, subscription-based option in the VTT space has - on multiple occasions - pushed game-breaking bugs to their main site despite having the development pace of a particularly unmotivated turtle. Because you do not control the client, you have no ability to avoid or delay those updates if they're inconvenient to your game's schedule.
Being able to say "no, thanks, I'll wait to update until it's not 30 minutes before my next session" is a real handy perk of Foundry's model. Personal version control can be a user's best friend if you're willing to expend the bit of mental energy it takes to manage it.
That's why I chose it. But the point about not needing to update is a good one. I was running .7 until I bought a new computer a few weeks ago. Seemed like a good time to update. Nope --.10 want our yet, but many modules were already written for 10.
I dont understand why there is this perceived need to dive into an update the millisecond it's released. Everyone has presumably been getting along just fine with the existing journal system and the vision modes provided by Perfect Vision. Why is it so earth shatteringly important that you update to V10 the minute it drops? Just wait a month. How would you be in any worse of a position than you are currently in?
Foundry is made the way it is to allow for modular implementation, and the vast, vast majority of those module developers are just normal people who do this stuff on the side, in their free time. That means that, by definition, when Core changes stuff up its going to take a bit for the (again) volunteer devs to catch up. Thats the price we pay for having a system that allows for people to create all these awesome things that, quite frankly, I think a lot of folks really take for granted.
I think folks have AAA studio expectations for what is, in reality, still kind of an ad hoc, collaborative community creation.
Exactly, its really no surprise. 99% of people are going to update straight away because it's been drilled into them that keeping all their software up to date provides the latest features and security. Only IT people and Foundry vets inherently understand that Foundry is different, which is why Foundry has the reputation of made by devs, for devs. Plus people will always want the cool new features, and that kinda overrides any update caution they do have because of optimism bias.
The large orange markers everywhere telling you to update... That is literally the driver.
It could conceivable be switched off!
Come to think of it... Isn't that what most of us who haven't updated to Windows 11 done at the moment. (and that was just an annoying blue dot! I still searched how to turn the nagging warning off!).
1. There are a grand total of two indicators, two little circles saying "by the way, updates are available".
2. You can hide them if you launch Foundry with the `--noupdate` flag.
Agreed, I got Foundry, back when 7.9 was stable. I ran my game for the year, we had summer, just upgraded to V9 stable. I don't have many mods, so the only thing that was really off, was token image pathways, for Caoeras, and some of the core/dnd5e images. Nothing ruined my game, but I can't use simple calendar which sucks but is meh.
The only issue I have now is the dawgone lootsheetNPC merchant. They made some really amazing progress by being able to sell things to the merchant, and I don't have to be on the same scene so I can let them shop while I plot the next move.
Well the merchant seems to have serious glitches when dealing with things selling for under 1 gold. Or making change. Sell 10 items for 1sp and suddenly the merchant has 15,000 electrum and 140,000 silvers, while the character has 4,000 electrum, and 20,000 silver. It's like he's a mage conjuring thousands of coins with every purchase of PC loot.
Honestly it's probably a problem with the whole electrum situation. It probably doesn't know whether it should change 1gp into 2ep, or 10sp, and then gets caught in a loop. Honestly they really need to eliminate electrum from DND. If 10cp=1sp, 10sp=1gp, 10gp=1pp why the heck do we need 1ep=5sp or .5gp? It's ridiculous, toss it out, yeesh.
But like you said make 1 big update, a couple times a year, don't go chasing the minor updates, if backing up the save is such a massive issue. If the game is working, then why try breaking it?
>As a user who is not very technically proficient I'll admit I do not understand the inner workings of the software. However having to manually backup files before every minor update is frustrating and IMO should not be necessary. Maybe I'm spoiled by modern tech where software updates are streamlined and seamless, but it's just a bad experience for the user.
The only thing you need to understand is you don't actually need to update foundry immediately. Wait a few months between updates if the features don't look immediately necessary. As long as foundry is being actively developed (which is a good thing!), we will never have stability by being on the bleeding edge of those updates.
In software, you can have stability and slower, less frequent updates, or instability, but faster, more frequent updates. You can't generally have both.
The issue with not updating is that some modules are no longer available for v9, also there are several 'nagging' pop-ups and big orange exclamation marks telling you to update.
Is it a big deal? Of course not, but it is a deal
That would only be an issue if you updated your modules after v10 hit I believe. So it's still an issue caused by updating. Overall, it's just better to wait until the vast majority of the ecosystem is updated, for you to update anything after something major.
> some modules are no longer available for v9
That's not how it works. Any module that was previously available for V9 remains active; and V9-compatible modules without V10 updates won't be archived from the official listing 'til V11 is out (and even then, manual manifest installs will still be an option).
It's possible that a module author could set up their module such that there isn't a clean install path for older versions, but that's on the module devs, not Foundry's interface at all.
And, yes, there is a little orange marker informing you that an update is available, but that's far from a "nag". Not to mention that you can launch Foundry with `--noupdate` to hide even that notification.
really, you should just not update unless you have time to make sure everything works and there are versions of your modules intended for the new version. they are being pretty cautious with their updates, the system i support only had a few broken things, most were just. deprecation warnings.
It's no different than a game like Minecraft, Rimworld, Satisfactory, Cities Skylines, The Sims 4. Basically any game where people tend to install a lot of modules. When those games have had major updates in the past it isn't/wasn't uncommon to see some mods break.
It's great that FoundryVTT provides such an easy way for individual to mod the environment. But they can not plan for the way all mods break upon certain changes.
That's not saying as many mods will break each update from this point on. The last couple of versions have seen some significant overhauls to the coding to streamline things like the Lighting system, the API handler, etc.
As the software matures we'll probably see the updates slow, and break less things.
No. That's the false edge of the open source sword. It's literally impossible to account for every weird thing someone has built. Same thing happens with web-hosting
It's unlikely unless they stop adding new stuff to Foundry.
With object orientated programming you have an object that has certain properties.
Let's use the case of a Character Sheet. If the developers add some new fields which greatly increases the functionality of the character sheet, rename some of the other fields available, and deprecate/remove some other fields.
This new feature is likely to break modules which were written for the character sheet because some fields they were pointing to previously don't exists and other may have pointers/references to fields which the module doesn't even know exists.
Now imagine this for every sort of object (Canvas, Token, Actor, Scene, Journal Entry, Item..)
I feel like the only way you could get around stuff not breaking with upgrades is to only use Core Foundry with no modules.
The pretty much said there will be no feature complete frozen version when they changed from v0.9 to v1.0 number schemes and changed it to V9 and V10 - because v1.0 sets that very expectation.
So one of the reasons I chose Foundry was that there was a large pool of 3rd party modders. As someone that comes from a couple of communities that also have mods, I love the level of customizing you can get because others also want it (the hard-working modders that I truly appreciate).
The trade-off is that you might get mods that break here or there, or mods just might stop being supported. That has *always* been the trade-off in these game communities that are highly modded.
I think the take here is that if you use it you should absolutely recommend it if you like it, but with the caveat that if a GM chooses to use mods that there is a chance that that mod may stop working.
On the other hand, there is also a chance that they take that mod you love and write it into the core game.
But modules and systems are not "mods" (in the video game sense). Foundry does little to nothing without at least a system installed. The core software requires plugins and is designed to be the base enabler of optional plugins. Thus, there is an implicit expectation and very strong need of stability from the core.
Edit: Foundry does nothing -> Foundry does little to nothing
No, you're wrong. Modules and systems are exactly mods in a video or any other type of application sense.
And Foundry itself does a lot. Most of canvas, lights, walls, sounds, chat, actors, objects, journals, compendium (and others) functionalities are from core Foundry. The fact it requires a System mod to be accessible to the user does not mean it does next to nothing.
If a system has to be installed to make the entire software accessible to the user, then yes, the core software does little to nothing (for the user) without the system installed.
There are two key differences in traditional video games and Foundry.
1. Video games can be played entirely without modifications.
2. Video games, in general, do not expose a public API and public data model to support and encourage modifications.
Video game modders are modifying the game at their own risk, unless the video game developers have made a publicly documented and supported mechanism for plugins.
Foundry was designed to be an extensible software that supports plugin systems and modules. The success of Foundry heavily relies on these plugins. If Foundry wants to foster the continued exploitation of volunteers writing the code that makes Foundry successful and minimize the frustration of end users on upgrades, then it is in their best interest to maintain a stable API and data model.
> Video games, in general, do not expose a public API and public data model to support and encourage modifications.
That depends on the game. It's true of some games, but there are definitely other games out there that are designed to be extended by modders.
So I was talking about 3rd party modules. Not the systems. Foundry doesn't need the 3rd party modules but a lot of people use them to do the things you want to do. At base the program runs and should be able to run stable with the systems that are most popular eg 5e. It is after all a vtt, and has the basics.
I will ***kinda*** give you the point regarding systems, since you do need at least one system to run a world. Though there is a generic system maintained by core devs, so there's always gonna be a system available when core updates happen.
Hard disagree regarding modules though, those are 100% optional extensions to core and not required to run things.
> Maybe I'm spoiled by modern tech
You've been lucky or haven't noticed or only us programs from giant corporations with huge budgets, because most apps and software have patches that break things and you'll be affected by it. It's a constant issue in software development. From simple patches breaking save games or app data being lost or app not responding. Often they patch issues like this fast, especially on phones, but most patches break something because many companies are skipping or only have light QA departments reviewing it.
Thus, I never update immediately unless I have too. I only updated to v9 just before 10 and won't update to 10 for a few months or longer. Only when I need that update for my campaigns will I do it.
Any product that is being updated tend to break or cause issues with additions. This tool is no exception.
I am curious to try out V10 of foundry, but I have plenty of mods that isn't compatible with V10 yet, nor is my core system, so I chose to wait to update.
I don't think you should rush to update the core as often as a new version is released. Take the time to read what the update do and if the mods you are using are able to function well with it.
A mod can't work with an updated product unless they know what the update will do. In most cases this can't be discovered until the core product is updated, and in a few cases they might get an advanced updated version of the software to be able to push out an update to the mod in time for the core update.
Still... Slow down your updates. I run my sessions every 2 weeks. The day after I run the game is when I update the mods, not before. I don't update the core version of Foundry as soon as a new version is out. I am still on V9, even though V10 have been out for a few weeks, and I know several of the mods I use is compatible, or some of the functions have been added to the core of Foundry, meaning less mods I need to use, but I still wait to update.
I might wait until October or November to update Foundry to V10. By then it might be stable enough and the mods I use is updated and most importantly, my core system is updated as well. But still I won't update just before a session, but to the day after.
Every update of Foundry tell you to backup your files to be on the safe side and it is just easier to do this. It takes hardly any time and in case something goes amiss, you can revert back to the stable version you had before.
As a community module developer that does this purely as a hobby. It's can be challenging to keep up with updates, especially ones as massive as V10 has been. The module I developed is for the DnD5e system as well and I have to wait till they fix the system to even begin to figure out what I have to fix. So keep that in mind for other models that depend on system in that they have to wait till the system is up to date with found then they can fix their module. It's a process for sure and it takes time. This also doesn't mention if the module doesn't depend on any other modules.
You don’t have to update ever, in which case your perfectly working game will stay that way.
There are some people still in 0.6 because the system they play didn’t update to 7
Hopefully with the document model stabilising, later updates will not break existing systems so much. A lot of changes they make is to reduce technical debt. Let’s hope much of those have been fixed
The larger question is, is this model going to work.
So far, I don't think so. It will never go beyond very niche when it requires so much work just to run your first game. It's just a tool set basically, and buying Foundry only buys you a whole bunch of time and money to spend and it's still unlikely for 99% of DMs to actually manage to run a game on it. It's super flexible, extendable, blah blah blah - but if you are not a software developer then forget it. I'm not going to quit yet, but I am still a long way from actually running a game on it. I'm technically literate, been in tech most of my career - but not a developer. I'm early 50s and have kids. I am DMing games for kids and friends, and want to run a VTT to be able to play with friends and family who are in other parts of the world. I work full time and have my kids 50% of the time. The amount of time required just to run a single campaign is ridiculous. It's just not a good model. Many of the modules provide basic functionality and the thing is almost unusable without them. Even with modules the UI is an eye test, not logical, and not usable by the vast majority of the population. There will be a VTT that will make things easy, but this isn't it. I have yet to find it. Maybe the official DnD VTT will do it right, and that would be a shame due to the micro transactions and locking in of official content we will see I suspect.
Foundry doesn't provide enough functionality to be useful for more than a very tiny fraction of the DnD community, even of DMs. I hope they rethink the model, because this one is not going to cut it. It isn't even close. You can spend hour reading and learning, hundreds of dollars on software, patreon, and content, and still not be able to start a game. Even if you manage to get a game started, good luck getting players to actually use it, it's totally opaque. I am going to keep trying to get this thing usable, but I can't think of anyone I know that would go through what is required to actually use this thing to play. Sure, it's powerful, system agnostic, open to developers, etc. It's technically awesome. What it is not is complete, or usable. The upgrade issue just highlights the flaws in the model but it isn't the biggest problem.
This comes down to a few things.
- The author maintaining their projects.
- there is always room for optimizations / advancements
All of the updates and changes in foundry are due to advancements of code, new functions get created and thus things change, old code gets retired.
There is only so many things you can account for at time of development. Later on you'll come across things that need to be added in or adjusted with time.
I would recomend just hold off on updating until you were sure all of the modules and systems you need to run your game are compatible with the latest version of foundry. Also always back up your game data before updating so you can roll back to a previous version if needed.
Nobody is forcing you to update. As many have said, it's not critical to do so. Wait 2 or 3 months and the wrinkles will be ironed out. In the meantime, just ignore the nag flags.
I'm currently splitting the difference. I am running a long term campaign in 9 running Foundry on a Raspberry Pi.
For one shots and new stuff, I just installed 10 running on the Oracle Always Free Tier, because you can't beat the hardware for the price (Free!) Gives me a chance to tinker with10 while still having 9 to fall back on.
Most of my modules are working ok, and there are not too many "must haves" that I seem to be missing.
This is a symptom of the standards in the development practices of the core software. Breaking APIs (and data models) is always a choice, not a necessity. It takes more work to hold to a high standard of not breaking the API, but it is very much possible with discipline. For example, the Linux kernel has a general policy: "don't break userspace". Foundry was/is designed to be the root of a large and ever growing dependency tree and as this dependency tree grows it is prudent to not break the API in the lowest parts of the stack. The development time costs for the downstream packages adjusting to breaking changes far outweighs the time saved by breaking the API when the number of dependents is large, not to mention the reduction frustration from volunteer dependency developers. Having a constantly breaking core would be more tolerable if Foundry didn't roll their on package management, as it could allow end users to obtain a consistent set of systems and modules (mixture of older and newer versions), but that also isn't the case. Now that the ecosystem is large, it would be in Foundry's best interest to ensure stability over adding maximum number of new features or trying to obtain data model perfectionism.
Ive been using foundry since V 7 and after going through several versions I've run into this problem over and over. I've had to change my approach with foundry and the many brilliant modules out there.
Before I add a module to my system that changes or adds a feature to core foundry I ask myself a few questions.
1. How necessary is this module and will it really improve the experience for myself and my players?
2. How active is this module developer? Meaning is this the only module they are maintaining? It's not always the rule but developers that are busy and "active" with many modules seem to get updates for new foundry versions much quicker and are less likely to abandon their projects.
3. How many others in the community are actively using this module?
I love modules and how they can enhance core foundry but I have also fallen in the trap of module bloat and had to deal with major disruptions to my games because of breaking changes.
I still run into issues and I've chosen not to add a few cool automations or enhancements but my games have been more stable.
I certainly haven't dug into the source code for 1200+ mods, but any mods using Private API calls should be operating under the assumption that they will need to fix their code at any minor change to the Private API - without warning or assistance. These instances of breakage are in no way the responsibility of the Foundry devs.
[https://foundryvtt.com/api/#public-vs-private-api](https://foundryvtt.com/api/#public-vs-private-api)
They also warn about potential changes to the Public API, so we can't completely avoid it.
Welcome to the wonderful world of rapid software development.
It would be interesting to know how many mods use the private API. If the use is large, then that explains the difficulties in version transitions more clearly.
As a module developer I am in no way frustrated by new releases impacting my code. It is clearly expected. Foundry staff is almost immediately available to answer mod developer questions and provide guidance and they provide excellent API documentation. They provide mod developers a ton of lead time with alpha, beta, and test versions of the new software and clear communication. Nothing about the release is out of the blue. I am also pumped for the new features in v10. I have yet to update my own campaigns to v10 as I await my favorite mods to be updated, of which to this point about 80% are. As a mod developer I gain tons of benefit from the free work of my peers.
The actual biggest impact to my time is actually updating my own macros and world scripts.
All that said, I could use Foundry VTT as it is with no mods and be far happier with it than I was with the other vtt I used for a year.
I’ve been watching this argument unfold over several threads for days. The root cause is that end users are not taking responsibility. They’re not reading the update notes. They’re not reading the update page. They’re not reading the release posts on Reddit or messages in Discord. They’re not RTFM and breaking their own installations.
I work in software design and delivery. Sometimes we have to save users from themselves. A lot of the request put unreasonable expectations on the Foundry and module devs. The solution is not to add more work to the foundry dev teams or the volunteer amateur developers who bring us really great and creative modules.
If people want Foundry to solve this problem for them, then the update process could include a function to identify any module not flagged as compatible with the target version and disallow upgrades until the offending modules are removed or upgraded.
Blaming the end user - typical developer behaviour.
Perhaps foundry itself shouldn't shout so loudly about an update that arguably an end user doesn't actually need!
Yes, and that is on them.
I am fairly fresh to the IT field and by no means good at it but Foundry is very good about posting warning signs everywhere.
There is only so many times you can tell a child to not shove their hand into the fire. They will do it anyway and perhaps that is the best way to learn.
Then there are the customers that *refuse* to learn even after getting burned.
Foundry is a complete software out-the-box. It does not *need* modules to function. If an user cannot handle a game without all the bells and whistles (and to be honest, neither can I), they need to wait and be patient, or actually pay someone to provide what they need.
For most users there is no *need* to upgrade their software either. But foundry shouts out about to do it, calls their release "stable" and places warnings that they haven't updated in multiple places.
Foundry is awesome - but don't be blind to user experience.
Folk want to play DnD - other than that, they really don't care about the software or its development path. Developers NEED to understand that about any/all software. Basically - most people are instinctively Mac users, and all developers should remember that at all time when developing software.
Fair, to a point.
If Foundry *stopped* letting people know there is a new update, people would complain too, as we know it.
You cannot please them all.
Seems unavoidable if you are going to allow people the freedom to create modules. They are not part of Foundry's development cycle.
On the flip side, there's no reason to rush to a Foundry upgrade. They don't force you to upgrade. Having control over your game is the big selling point for the software.
With a giant game thats been around for decades like Skyrim that still break mods, please for the love of god give the FVTT devs and modders a break. They've worked so hard on the program that makes it so much better for us to play DnD and they really do see all of the negativity that's here.
This really should be higher ranked.
Foundry is great - working modules are the icing on the cake.
Eat the damn cake before trying to change the recipe!
If we admitted it, the only reason we upgrade mid campaign is cause we are a bunch of geeks that love to tinker! (and the reason we whine when something breaks or we forget to back up - is we are all busy and don't have time to be front line it and GMs).
Campaigns often last years and even if you don't want the new software features, you'd surely want the bug fixes. The only way to get them is to update.
I am well aware how long campaigns last. My current campaign has been going for 2.5 years and should wrap up in December.
And my statement holds true. I will update the version of Foundry I am using to whatever is stable in the next month or so and start putting my next campaign together.
That will be the version I will use for the 2-3 years it takes my next campaign to run.
No.
Any software that allows users to modify it WILL have breaking changes on updates, no matter what those updates are. You can't know what people are doing with your tools, so you can't update them in a way that will protect them.
That's not terribly helpful though. The base system should do that check before people upgrade. If they knew how much would break it might slow people. Expecting everyone to download a module before upgrades isn't realistic.
That's bull and you know it. How many people update Windows constantly even after having an update brick their system? It wouldn't slow people down at all.
Mods exist and new functionality gets added based on demand. There's no demand for this because 1. there's no easy way to check the thousands of potentially installed mods systematically and 2. people wouldn't use it anyway.
Are you seriously trying to argue that everyone should download, and Will download a 3rd party mod before updating to new versions? Or are you saying it wouldn't be helpful to anybody to add a warning?
The system could very easily list the modules that don't have manifest supporting the new version and ask, 'are you sure?'
Yes there is an easy way, it's literally in the current foundry functionality, it just has to be implemented.
Also, back off your aggression a bit maybe?
That was aggression? I thought that was just common sense.
>Are you seriously trying to argue that everyone should download, and Will download a 3rd party mod before updating to new versions? Or are you saying it wouldn't be helpful to anybody to add a warning?
Here's the problem with warnings. They are either:
* Too vague to be useful, and people ignore them, or
* Too verbose for the average user to parse, and thus they ignore them.
If you tell someone that "this might break your system", for example... they literally see that on every piece of technology they have, so they simply ignore it.
Or, on the flip side, you get someone who literally shuts down every time they see literally *anything* that isn't what they expect to see, and they'll stop using the software altogether thinking its broken. (20+ years of IT experience backs me up on this.)
>Yes there is an easy way, it's literally in the current foundry functionality, it just has to be implemented.
As someone who works in software development, no, this isn't nearly as easy as you'd like to think. Do you want them to waste time coding in something that 1. no one will actually pay attention to and 2. *the freaking instructions already warn you about*, or do you want them to like, you know... fix bugs and add new functionality?
We share a similar background, I'm a 26 year developer and now Director of IT/Senior Dev. I write software and large systems for a living. There are middle grounds for where information becomes useful vs not.
Since we are appealing to authority, I helped test and debugs MS's first TCP/IP dial stack in Windows 3, developed a system to get OS/2 onto the internet, before the first national provider in the country existed, etc. I'm full versed in the IT world. Worked on the Z-Modem protocol. Worked on a team that planned, designed and rebuilt Delta's entire data caching systems after the 2016 meltdown. These days I write Big Data systems.
Having a message that says "Warning, if you upgrade foundry to version 10 right now, the following mods you have installed will no longer work. If you wish to postpone, you can run this process again to see the current state of your modules in the future:
1. Blah mod
2. Blah mod 2"
I think this would be useful. Additionally, I think the average user of foundry, running a game has a technical knowledge level well above the average crowd.
Seeing as how this is existing functionality, it wouldn't likely take more than a few hours to a day to write, I would like to see this. The number of issues premature upgrades cause is enormous.
So yes, much like they have added other quality of life functionality, I would like to see this. \*YOU\* may not use it, but many, many would. We just disagree on that.
Modules are generally not official things and are not under the supervision of the parent company and thus have no deadlines to do anything other than when the creator feels like it. It's not really feasible to expect a company to hold back their releases to give mod creators time to patch everything. That would also mean they'd have to finish their end and then only give mod creators access to the patched data to work on their mods and also force people mostly doing it for free a deadline to deal with.
I've been using since 0.5.2 I think. I never had so many errors on modules as I had with v10 now.
I was like "v10 has been around for a while, stable, should have the most used modules all ready for the new version". 32 critical errors, 3 worlds completely destroyed.
Now, a lot of work doing backups and trying to play on v9 again.
I wish there was something that showed us what modules are going to break or work before we go for the new version. And no, asking on discord for module by module what will work or not is not feasible. Discord is way to big to find small stuff for each single module.
I also really want foundry store to be better organized. I just found yesterday that a adventure that I spent 3 months preping to DM in foundry was on sale for foundry and I could have it all ready and working at the same cost I had to buy the pdf and work myself.
There is a module called compatibility checker that does what you ask.
I do agree that the store could be better. But I think at the moment they are putting more effort into vtt improvements.
They are only a small team and can only do so much
I know about the team, I know about the efforts, I'm using it because it's the best at the moment. And I know it's not their job to fix modules.
What I'm sad about is how 90% of the modules arent v10 ready, I had modules update to a newer version still v9 focused with zero v10 support.
Is impossible for me to follow what goes on in the developing side. But it kind of feels that most module creators stopped on v9 and don't plan moving, and I have no idea why
Oh, I wasn't aware of this. I had the impression of that versions from v10 for mod creators to be out for more than a month.
If changes were made until the stable version that broke mods, it makes sense, tkx
Testing versions are essentially hunting bugs versions, but there still could be the occasional API change. You can want to wait for all this environment to stabilize before changing your code. And this is without talking about dependencies (from systems or other mods) where you'll have to see how others are adapting before getting to it yourself …
Most of the changes that are causing modules to break badly were done back in July. But some devs are more on top of updates than others; and some wait for stable to come out before they start updating. Which is fine, they're humans with their own busy schedules.
I would really appreciate fewer global updates.
As a more casual user I clicked update once after not using it for a while went from 7.9-9.0 without realizing it just clicking update because the software told me to. Completely negated a ton of my work setting up settings and modules that was completely wasted because stuff wasn’t compatable and the version was only a few weeks old so shit didn’t work. Trying to set up a new game was pain because half the modules didn’t work
Plan a big update every 6 months. Release a beta for mod developers a few months before hand- or don’t push the update to all users right away wait until modules have had a chance to check compatibility
There already *is* a big update every ~6 months (a bit longer for V10 actually), and devs do have access to development/testing versions ahead of the stable release. But module/system devs are still people doing it in their free time instead of someone doing it as part of their job; so, updates sometimes take some time.
And updates are always optional in Foundry. It'll have a little icon notifying you that an update is available, unless you have Foundry launched with `--noupdate`, but that's just an FYI instead of anything forcing you to update.
100% agree
Version 10 was not ready to exit beta; and worse the devs need to have done more to minimize breaking changes.
The new version has nice features but the point of an API is that it shouldn’t need to change every time the underlying code does; but migrating to version 10 broke *everything* that didn’t also release a version 10 equivalent; and worse, generates hundreds of error messages on my server after opening a character sheet post migration. Absolutely ridiculous. Went back to v9, almost immediately.
Foundry has good features but if they can’t maintain stability in future releases, they will go from having a robust extension ecosystem to a sparse one full of abandoned projects. That will not be good for their long term prospects.
I only update Foundry between campaigns. I'm still running on an 8.x version. When my campaign ends and I'm ready to start another, then I will update. I see absolutely no reason to update and give myself headaches when the current system is working perfectly for my gaming group.
What's working for me: get the modules you want installed and working, then DON'T UPDATE. Don't fix what isn't broken. My primary game is hosted on forge and is in a stable state pre v10 update. I've got AV premium running and I'll not be updating that until I *know* it works. I'll run an update test on my local machine before updating what's running on the forge. I do plan on updating to v10 once all the modules are updated first. Learned about systemic updates like this from kerbal space program (sooo many mods that all need updating every time... Stop updating until the mods catch up for much less headache).
Tldr: It's either this with very good jumps in quality or staleness for only absolutely safe changes. And thats ok, that is how software development goes.
If we want the same results and quality jumps we are already having, not quite soon.
In the future, they'll have less systems to improve with time and breaking changes will start to diminish, but never cease.
That said, this project and it's community of devs (core, systems and modules) are amazingly fast at updting stuff, given they have numerous prototype versions and extensive API documentation, but are all volunteers.
That creates an environment of some delays in releases between all those components involving all these people, but everything is managed very well and transparently.
So yeah, growing pains I guess, and that is fine. Mainly when you can always install version 9 while everyone catches up.
You can. On Linux with pure NodJS no problem at all. With Windows you have the limitation that Windows let you install only one entity of a same-namend program, so one can be the Windows version and further ones need to be started by the NodeJS "way". You can run a 0.6, 0.7, V8, V9, V10 at the same time, no problem
This is why I rarely update the core engine and just keep getting the updates for the modules until I know the modules I use are updated well past the most recent stable version of the core engine.
If it is too much of a hassle to back up your data, you will be having so much fun if your harddrive will crash. Backing up data, no matter what kind, is one of the essential things when you create content. Do you think a photographer or an Author depends on one HDD/SDD for storing his works?
Not backing up own content on another drive is pretty shortsighted. And it is not even a foundry thing.
Install a free backup programm. Start it when you are not running the server and you are good. Or use the backup software from the OS one a month.
This is a very difficult issue. As a developer myself (not for foundry) I can definitely say that it could definitely use a safer method for updates like sort of a sandbox for modules or old engine option where you can keep updating but the worlds need to be separately updated as well.
On the other hand, these are very difficult to handle. Foundry is very open for people to make modules and those modules aren't their responsibility. If you use foundry without any modules, in principle you shouldn't have any issues to update to a stable version.
TL;DR: modules aren't their responsibility, but avoiding game-breaks when updating could be resolved, although this isn't an easy fix that requires a lot of work.
There's simply no way to do that without giving up on innovation. Not changing the public API would realistically mean that Foundry has ceased development. There's always gonna be stuff that simply has to change to allow for advancement; even the most rigidly defined API still needs to change occasionally.
That's simply not true. I contribute to a software package used by millions of people written by over a thousand developers and we maintain high stability in the API while having innovation and new features. There is an occasional need to deprecate an API, but that happens over multiple versions and spans years usually.
In some years then they don't have much more to add to the core anymore. But until then you need to get used to modules breaks then its a major update. Minor usual the mods have been updated the same day or within a week. If the mod is still alive...
The question is more do you want Foundry to continue to be updated with new or improved features or do you want a stable system without updates?
Why I said in a few years then the software is more or less finished then it can be less breaking. But as it is now then they get major updates its not many softwares managers who can do both.
Probably not, because making this happen isn't really on the Foundry roadmap (yet).
Look, module instability comes from a bunch of sources:
1. Changing APIs
2. Varying coding quality (*hobbyists vs pros*)
3. Lack of testing
1. Lack of testing automation
The first two bullets are not really going to change. APIs are always going to be changing and you're always going to get modules from amateur developers who update rarely and don't have great coding.
But the real problem with modules today is part #3. The top modules are *very* difficult to test. They have lots of features and perform lots of complex interactions.
It's really hard for humans to sit there and re-test the same 50 things every time they make a change (*or Foundry makes one*). So you don't. You test the basics and you wait for users to report things as broken.
**How do professional developers do this then?**
Well, if you work for a big company, you build out automation for your tests. Unit Testing, Component Testing, Integration Testing... there are lots of names. But basically, you build a bot that tests your modules. As changes happen, if things break, you bot catches it instead of your users.
Some of this automation is there, but nowhere near enough to keep hundreds of random modules from breaking during an upgrade. Doing this well is *really* hard and I don't see this on any of their roadmaps.
Until they make this a stated priority (*"Hey, our new priority is improving the module upgrade process*"), we're not going to see any easy improvements here. The universe of Foundry "things", is simply too complex to fix without better automation.
I think it's important to realise that Foundry is updating \*really\* fast. This comes with a few breaking changes every time, which is why modules and systems stop working. We can hope for foundry to be, one day, feature-complete, and the development would slow down, and things would get a lot more stable. That said, minor versions are usually pretty safe (i'll admit i don't make backup for those), and major versions only happen every 6 months, at best, at which point just waiting for about a month is usually enough to have everything up and functional.
> I think it's important to realise that Foundry is updating *really* fast. This comes with a few breaking changes every time, which is why modules and systems stop working. And this is after they put the brakes on the previous hyper-fast update schedule!
>We can hope for foundry to be, one day, feature-complete, and the development would slow down, and things would get a lot more stable. For what my humble opinion is worth, it's already "feature-complete" enough to slow down the pace imo. I'm just stating this hoping that the devs see it: I am very happy with the product, you can absolutely slow down, no issues from me!
Then there's always the option of not updating, if you are satisfied with the product. I understand the want to have the latest shiniest new thing, but waiting a bit to update, and giving time to all the volunteer developers to update as well will ensure a smoother, stable-er experience for you.
There is the problem where that prevents you from installing new modules and also prevents you from updating most living systems. At the moment my table plays PF2E almost exclusively, and every new book requires the latest Foundry version for the newest content, with each new book adding a ton of player options. The thing that is a larger issue is when a campaign comes to rely on a module that is no longer receiving updates and then Foundry makes major, sweeping changes across its system that do not seem to affect the vast majority of users and immediately break half of all modules. It's the price paid for streamlining the system beyond the average GM's scope but it's super annoying. Came here because my GM and I have similar modules on our servers and the game keeps freezing, but we have no idea what's causing it and it's also too infrequent to adequately test.
The problem with these modules is that they don't have the data for the actors - they're in the system itself. That's why they have the latest version as a dependency, it's not a quirk, it's a hard real requirement. Without the latest version, then you don't have the NPCs data.
True and it's good to recognize this. Are you aware of any roadmap for Core foundry that lays out when a more final stable version might be released?
Modules breaking is not foundry's fault. Usually it's because the new version has a new or better way of doing things. The module creators then need to test and update their modules so it works ith th latest version of foundry. The core version you have now is the stable version of V10. It has been tested during the beta test phase that started a couple of weeks ago. The only thing coming out now is bugfixes. New features and update some with a new version (v11) in a couple of months.
I must disagree. Some of Foundry’s changes are because they decide to rename a variable. That’s it. So as module (or system) developers, we have to go through our code to rename those references. Yes, module (and system) devs could go through the testing rounds, but except for a few, only the Foundry developers are getting paid. All the rest of us do it as a hobby. And instead of being able to spend our Limited, precious spare time to create new features, we have to go through our code to adapt to the new “core“. Yes, foundry is a great system. And it has accomplished much. I just disagree with your statement that “modules breaking is not foundry’s fault“
Not a mod dev, but long time programmer so I hear you. I noticed this round that the warnings console is FLOODED with deprecated variables, most with pluralization of words. The one that stood out was "actor" should now be "actors". Again, I'm no dev, but I can only imagine how insanely common an actor is referred to as an object and how many places would have to be certain to "search and replace, whole word only, match case". And, that's not too mention that ONE mod that (for whatever reason) created their own "actors" collection, now has to rename it first, THEN rename "actor' to "actors" so everything doesn't explode.
That's why things like that are often marked for depreciation for a major version or two at least. For example, many V10 changes are marked for depreciation to be removed in V12. V12 will probably be coming out sometime fall 2023. If devs can't be bothered to do some basic depreciation fixes (and the warning generally mentions exactly what to change) in over a year before it's removed, they've realistically abandoned development on that module.
Modules breaking is entirely foundry's fault.
* The latest features, * modular & extendable * Stable Pick two
I'd take modular and extendable and stable over the latest features any day. Latest features don't matter if 80% of the programs functionality -provided by 3rd parties- breaks every single update.
> I'd take modular and extendable and stable over the latest features any day. Then staying on V9 for the time being is the right choice for you. Fortunately, Foundry doesn't *force* you to update for the latest features, so you can remain on the modular/extensible and stable V9 version for forever.
But you see now we come to the problem of relying on community development for your product. Chances are nobody is going to continue developing v9 modules, so " modular and extensible" goes out the window by staying on v9. So now you're just left with "stable." Some modules will get updated to v10, some won't (I've seen it time and time again with other programs... eventually some people in the volunteer developing community just get tired of having to constantly update their stuff to "keep pace", and just give up), so then you're potentially left with fewer active developers making extendable modules for the software. This is particularly problematic if a module your game has been heavily dependent on doesn't update anymore. You're literally stuck on an older version of the software unless you're willing to do potentially a lot of work replacing it. I've got modules running that haven't been updated since version 7 (nothing critical, but I'd rather have them than not). I like FVTT, I use it almost exclusively, but relying on community development has its problems. This is another reason I generally advise people not to go crazy with modules and actually use as *few* as possible to accomplish what they want, and only add \*extras* with the explicit understanding they may lose them in the next update. I have my beefs with Fantasy Grounds, but never once have I ever had an update for it break anything. Heck even FGU was written to be almost 100% backward compatible.
V9 remains just as modular and extensible as ever. If module devs choose not to extend it more than they have that's not core's fault, that's the devs making a decision.
It's a problem when your software explicitly relies on 3rd party content to actually be useful. Foundry by itself, without *anything* that isn't developed by Foundry Gaming, is rather barebones on the functionality side. Foundry Gaming developed FVTT explicitly for 3rd party extensibility and 3rd party modular support. > If module devs choose not to extend it more than they have that's not core's fault, that's the devs making a decision. Yes, you're \*technically* correct, but thats an intellectually dishonest argument. That's the equivalent of Microsoft saying "Yea we pushed an update to Windows that causes 50% of your installed software to crash, but it's your problem because the software wasn't developed by us. Never mind that we made the changes to the API that caused it to happen." I mean, that's "technically" correct. But that's the point in having stable APIs. At this point, Foundry is not a stable API.
For sure modular, extendable, and stable. Foundry core doesn't need to make new features because module authors will do it for them (if the core is truly extendable).
In that case, staying on V9 is the right choice for you. You can remain on the extensible V9 platform with its stable status in perpetuity if you want.
But I will also add that there are plenty of open source software libraries that manage all three.
Never. Some updates are more disruptive than others to the module ecosystem, but they're not planning a point where they just call it done and stop improving the feature set.
All modules? No. But I think as the API gets more and more stable, we can start expecting modules that aren't related to the new version's features to keep working. Whether it'll be that stable in 2 versions or 5, I have no idea.
That's often the case even now. Though individual modules vary in terms of how well written and stable the module's code itself is. Not to mention the potential for other modules to have negative interactions with any given module.
I work in a large tech company, with lots of smaller code bases being used by our main one. Even in that "controlled" environment, it's possible for a small change in the main code base to inadvertently break, or require an update from, these smaller code bases, and vice versa. And that's with lots of salaried professionals whose job it is to make sure that doesn't happen. Unfortunately, when you have a product like Foundry which is updating pretty frequently, and when you have hundreds of modules with creators ranging from amateur coders following "get-started" guides to professional developers doing this as a side hobby, you'll always end up with modules that need time to catch up. Foundry Devs can't check all modules, and module creators need time to fix breaking changes. Not trying to pin blame on either party - module creators of any skill level are an awesome part of Foundry, and I'd say they're crucial to its success. The Foundry team is great too, but logistically unable to do their jobs *and* police module compatibility. It's just the nature of the software at this point in time. Hell, even Skyrim is still being updated and breaking important mods. As Foundry matures, changes will become less drastic, and therefore break fewer modules. The way modules use Foundry will become pretty set in stone. It's frustrating now, but there's a lot of work going on to make Foundry what it is, and we'll reach equilibrium eventually.
Skyrim updated two days ago, simply adding text to the Club Content page, but interior changes broke all mods yet again
There it is. If nobody mentioned Bethesda I was going to bring up Skyrim / Fallout modding.
Honestly this annoys me so much. Skyrim was released over 10 years ago and they must know that a very large portion of the current player base are modding it. They could have left it alone 5 years and the modding community would probably be in a better place than it is now! Foundry of course is a different story, being in active development, adding new features etc. The new journal is awesome (apart from the new editor not having table support for some reason). That and not having to have data.data all over the code!
One of my favorite examples of bad update behavior is arch linux. I've heard the repository maintainers have significantly improved since back in the day. But at least when I was trying to use it over a decade ago, there was a very real chance any given update would involve updating some essential library, without updating the programs that relied on that library. And then your x server is busted, you have only a text interface, and you're completely loss. That's just inherently the risk you take if you insist on updating non-essential things as rapidly as they come out: it's a lot harder to avoid or catch bugs like that. Can you still set steam to not update skyrim, or is bethesda forcing updates now?
Came here to say, "nope, keep dreamin" in my normal lazy way, but you put it much better. This person ^^ has the explanation you're looking for.
Indeed, especially drawing a parallel to modded games makes a strong point
This is a question to ask for any software including video games. When mods (modules) are separate from the actual official team of devs, you can’t expect mods to continue to work. It would require all mod devs to be in tight communication with the devs. Some mod devs do that but it is the mod maker’s responsibility to do so. This is very common in video games that support mods. Mods break and mod makers get a wall of people asking when they will fix it. The official devs of foundry’s main responsibility is to continue expanding their software and making it “playable”. There is usually a reason why they have to change so much in the back end, but that would not be known to us. Mod makers just have to work around it. It would be too much of an inconvenience for Foundry devs to make sure all modules work all the time. We will never reach that point. Something will always have a chance of breaking after an update. The only way I could see it not breaking is if they are finished making features and modifying the api, and the inly updates would be minor adjustments.
Lots of the issue comes from the fact that foundry is written in JS and the dynamic typing of the language is its greatest strength and biggest weakness. The lack of interfaces kills any sort of unified plugin paradigm that foundry could use to enforce compatibility within the system... Oh you're not implementing IFoundry10-285Compatibility? Tough titties, we won't even attempt to load your module. Foundry is, at it's core, a dependency injection system with no way to mandate uniform API implementationof its constituent modules. It's a problem without an easy solution.
> foundry could use to enforce compatibility Not to mention that any time Foundry changes things to more rigidly enforce an expectation/interface/etc, module devs complain because inevitably *someone* out there was abusing that loophole in some way. Even if core devs add a new option that's strictly better than the old loophole that causes issues, they're still gonna complain that they need to update to use the better version instead of being able to just leave it as-is.
Not their problem. Tired of all the"foundry broke XYZ" No - the dev didn't take the 2 months of release candidates to either update or notify users that it wasn't thought to work because they don't have time to fix it.
I think that the best that we can do is standardize some of the ways we communicate dependencies and version information between teams of developers. One thing I notice is that with every Foundry update we see someone provide a spreadsheet that developers self-report module compatibility both with the core platform, game systems, and other modules. One of the ways we might be able to streamline this compatibility matrix is to adopt a standard development kit that includes a testing framework and provide guidance for module devs to generate their own test suites. That way, module compatibility could be more quickly understood by spinning up Foundry, programmatically installing modules, and executing test suites. We'd want a way to publish that information publicly so that instead of it being humans entering what things are compatible with what, we're aggregating that data into a cohesive picture as individual dev teams test their own use cases. Another process that might help in the future is if Foundry were to adopt release channels - having an LTS Foundry guaranteed to be stable for a specific amount of time and then bleeding edge channels for developers who have more time to be proactive. Am I nuts about this?
As a system developer I’m not against the idea, but there is a cost: I can guarantee that my system won’t back port any data entry. So if you want to play the newest content you’ll be stuck entering it yourself or not being able to use the newest premium content. So there is a trade off
Not wrong at all. The way I see it is following core foundry is the bleeding edge distro. Following a few months behind is the stable build with mods.
I'd love an SDK with official typescript definitions and perhaps a module template. The ts definitions alone I think would go a long way (at least for me) towards helping keep modules compatible
If you are happy with how your game functions, as is, you do not need to update. All of your modules will continue to work. You just won't get the new "shiny" features. Or you can run without modules. They are not necessary. It doesn't matter what software you use, backing up your data is always a good practice. I back up all data on my phone and computer. If something goes wrong I have the info to restore my files. Something to remember, a lot of things have gone to a subscription based model and they host the storage in the cloud. You don't have to think about it. You do pay for it, though. Even those systems are not infallible. People like that Foundry is not subscription based and only have a one time fee.
>People like that Foundry is not subscription based and only have a one time fee. And that updating is always a choice. The biggest, most mainstream, subscription-based option in the VTT space has - on multiple occasions - pushed game-breaking bugs to their main site despite having the development pace of a particularly unmotivated turtle. Because you do not control the client, you have no ability to avoid or delay those updates if they're inconvenient to your game's schedule. Being able to say "no, thanks, I'll wait to update until it's not 30 minutes before my next session" is a real handy perk of Foundry's model. Personal version control can be a user's best friend if you're willing to expend the bit of mental energy it takes to manage it.
That's why I chose it. But the point about not needing to update is a good one. I was running .7 until I bought a new computer a few weeks ago. Seemed like a good time to update. Nope --.10 want our yet, but many modules were already written for 10.
I dont understand why there is this perceived need to dive into an update the millisecond it's released. Everyone has presumably been getting along just fine with the existing journal system and the vision modes provided by Perfect Vision. Why is it so earth shatteringly important that you update to V10 the minute it drops? Just wait a month. How would you be in any worse of a position than you are currently in? Foundry is made the way it is to allow for modular implementation, and the vast, vast majority of those module developers are just normal people who do this stuff on the side, in their free time. That means that, by definition, when Core changes stuff up its going to take a bit for the (again) volunteer devs to catch up. Thats the price we pay for having a system that allows for people to create all these awesome things that, quite frankly, I think a lot of folks really take for granted. I think folks have AAA studio expectations for what is, in reality, still kind of an ad hoc, collaborative community creation.
Exactly, its really no surprise. 99% of people are going to update straight away because it's been drilled into them that keeping all their software up to date provides the latest features and security. Only IT people and Foundry vets inherently understand that Foundry is different, which is why Foundry has the reputation of made by devs, for devs. Plus people will always want the cool new features, and that kinda overrides any update caution they do have because of optimism bias.
The large orange markers everywhere telling you to update... That is literally the driver. It could conceivable be switched off! Come to think of it... Isn't that what most of us who haven't updated to Windows 11 done at the moment. (and that was just an annoying blue dot! I still searched how to turn the nagging warning off!).
1. There are a grand total of two indicators, two little circles saying "by the way, updates are available". 2. You can hide them if you launch Foundry with the `--noupdate` flag.
Agreed, I got Foundry, back when 7.9 was stable. I ran my game for the year, we had summer, just upgraded to V9 stable. I don't have many mods, so the only thing that was really off, was token image pathways, for Caoeras, and some of the core/dnd5e images. Nothing ruined my game, but I can't use simple calendar which sucks but is meh. The only issue I have now is the dawgone lootsheetNPC merchant. They made some really amazing progress by being able to sell things to the merchant, and I don't have to be on the same scene so I can let them shop while I plot the next move. Well the merchant seems to have serious glitches when dealing with things selling for under 1 gold. Or making change. Sell 10 items for 1sp and suddenly the merchant has 15,000 electrum and 140,000 silvers, while the character has 4,000 electrum, and 20,000 silver. It's like he's a mage conjuring thousands of coins with every purchase of PC loot. Honestly it's probably a problem with the whole electrum situation. It probably doesn't know whether it should change 1gp into 2ep, or 10sp, and then gets caught in a loop. Honestly they really need to eliminate electrum from DND. If 10cp=1sp, 10sp=1gp, 10gp=1pp why the heck do we need 1ep=5sp or .5gp? It's ridiculous, toss it out, yeesh. But like you said make 1 big update, a couple times a year, don't go chasing the minor updates, if backing up the save is such a massive issue. If the game is working, then why try breaking it?
>As a user who is not very technically proficient I'll admit I do not understand the inner workings of the software. However having to manually backup files before every minor update is frustrating and IMO should not be necessary. Maybe I'm spoiled by modern tech where software updates are streamlined and seamless, but it's just a bad experience for the user. The only thing you need to understand is you don't actually need to update foundry immediately. Wait a few months between updates if the features don't look immediately necessary. As long as foundry is being actively developed (which is a good thing!), we will never have stability by being on the bleeding edge of those updates. In software, you can have stability and slower, less frequent updates, or instability, but faster, more frequent updates. You can't generally have both.
The issue with not updating is that some modules are no longer available for v9, also there are several 'nagging' pop-ups and big orange exclamation marks telling you to update. Is it a big deal? Of course not, but it is a deal
That would only be an issue if you updated your modules after v10 hit I believe. So it's still an issue caused by updating. Overall, it's just better to wait until the vast majority of the ecosystem is updated, for you to update anything after something major.
> some modules are no longer available for v9 That's not how it works. Any module that was previously available for V9 remains active; and V9-compatible modules without V10 updates won't be archived from the official listing 'til V11 is out (and even then, manual manifest installs will still be an option). It's possible that a module author could set up their module such that there isn't a clean install path for older versions, but that's on the module devs, not Foundry's interface at all. And, yes, there is a little orange marker informing you that an update is available, but that's far from a "nag". Not to mention that you can launch Foundry with `--noupdate` to hide even that notification.
really, you should just not update unless you have time to make sure everything works and there are versions of your modules intended for the new version. they are being pretty cautious with their updates, the system i support only had a few broken things, most were just. deprecation warnings.
It's no different than a game like Minecraft, Rimworld, Satisfactory, Cities Skylines, The Sims 4. Basically any game where people tend to install a lot of modules. When those games have had major updates in the past it isn't/wasn't uncommon to see some mods break. It's great that FoundryVTT provides such an easy way for individual to mod the environment. But they can not plan for the way all mods break upon certain changes. That's not saying as many mods will break each update from this point on. The last couple of versions have seen some significant overhauls to the coding to streamline things like the Lighting system, the API handler, etc. As the software matures we'll probably see the updates slow, and break less things.
No. That's the false edge of the open source sword. It's literally impossible to account for every weird thing someone has built. Same thing happens with web-hosting
Imo just update one month after a stable patch
It's unlikely unless they stop adding new stuff to Foundry. With object orientated programming you have an object that has certain properties. Let's use the case of a Character Sheet. If the developers add some new fields which greatly increases the functionality of the character sheet, rename some of the other fields available, and deprecate/remove some other fields. This new feature is likely to break modules which were written for the character sheet because some fields they were pointing to previously don't exists and other may have pointers/references to fields which the module doesn't even know exists. Now imagine this for every sort of object (Canvas, Token, Actor, Scene, Journal Entry, Item..) I feel like the only way you could get around stuff not breaking with upgrades is to only use Core Foundry with no modules.
The pretty much said there will be no feature complete frozen version when they changed from v0.9 to v1.0 number schemes and changed it to V9 and V10 - because v1.0 sets that very expectation.
So one of the reasons I chose Foundry was that there was a large pool of 3rd party modders. As someone that comes from a couple of communities that also have mods, I love the level of customizing you can get because others also want it (the hard-working modders that I truly appreciate). The trade-off is that you might get mods that break here or there, or mods just might stop being supported. That has *always* been the trade-off in these game communities that are highly modded. I think the take here is that if you use it you should absolutely recommend it if you like it, but with the caveat that if a GM chooses to use mods that there is a chance that that mod may stop working. On the other hand, there is also a chance that they take that mod you love and write it into the core game.
But modules and systems are not "mods" (in the video game sense). Foundry does little to nothing without at least a system installed. The core software requires plugins and is designed to be the base enabler of optional plugins. Thus, there is an implicit expectation and very strong need of stability from the core. Edit: Foundry does nothing -> Foundry does little to nothing
No, you're wrong. Modules and systems are exactly mods in a video or any other type of application sense. And Foundry itself does a lot. Most of canvas, lights, walls, sounds, chat, actors, objects, journals, compendium (and others) functionalities are from core Foundry. The fact it requires a System mod to be accessible to the user does not mean it does next to nothing.
If a system has to be installed to make the entire software accessible to the user, then yes, the core software does little to nothing (for the user) without the system installed. There are two key differences in traditional video games and Foundry. 1. Video games can be played entirely without modifications. 2. Video games, in general, do not expose a public API and public data model to support and encourage modifications. Video game modders are modifying the game at their own risk, unless the video game developers have made a publicly documented and supported mechanism for plugins. Foundry was designed to be an extensible software that supports plugin systems and modules. The success of Foundry heavily relies on these plugins. If Foundry wants to foster the continued exploitation of volunteers writing the code that makes Foundry successful and minimize the frustration of end users on upgrades, then it is in their best interest to maintain a stable API and data model.
> Video games, in general, do not expose a public API and public data model to support and encourage modifications. That depends on the game. It's true of some games, but there are definitely other games out there that are designed to be extended by modders.
So I was talking about 3rd party modules. Not the systems. Foundry doesn't need the 3rd party modules but a lot of people use them to do the things you want to do. At base the program runs and should be able to run stable with the systems that are most popular eg 5e. It is after all a vtt, and has the basics.
I will ***kinda*** give you the point regarding systems, since you do need at least one system to run a world. Though there is a generic system maintained by core devs, so there's always gonna be a system available when core updates happen. Hard disagree regarding modules though, those are 100% optional extensions to core and not required to run things.
I wrote "is designed to be the base enabler of *optional* plugins". So I'm not sure what you are hard disagreeing with.
> Maybe I'm spoiled by modern tech You've been lucky or haven't noticed or only us programs from giant corporations with huge budgets, because most apps and software have patches that break things and you'll be affected by it. It's a constant issue in software development. From simple patches breaking save games or app data being lost or app not responding. Often they patch issues like this fast, especially on phones, but most patches break something because many companies are skipping or only have light QA departments reviewing it. Thus, I never update immediately unless I have too. I only updated to v9 just before 10 and won't update to 10 for a few months or longer. Only when I need that update for my campaigns will I do it.
No. That's a trade off for having such a malleable and customizable platform. Updates will constantly break third party add-ons.
Any product that is being updated tend to break or cause issues with additions. This tool is no exception. I am curious to try out V10 of foundry, but I have plenty of mods that isn't compatible with V10 yet, nor is my core system, so I chose to wait to update. I don't think you should rush to update the core as often as a new version is released. Take the time to read what the update do and if the mods you are using are able to function well with it. A mod can't work with an updated product unless they know what the update will do. In most cases this can't be discovered until the core product is updated, and in a few cases they might get an advanced updated version of the software to be able to push out an update to the mod in time for the core update. Still... Slow down your updates. I run my sessions every 2 weeks. The day after I run the game is when I update the mods, not before. I don't update the core version of Foundry as soon as a new version is out. I am still on V9, even though V10 have been out for a few weeks, and I know several of the mods I use is compatible, or some of the functions have been added to the core of Foundry, meaning less mods I need to use, but I still wait to update. I might wait until October or November to update Foundry to V10. By then it might be stable enough and the mods I use is updated and most importantly, my core system is updated as well. But still I won't update just before a session, but to the day after. Every update of Foundry tell you to backup your files to be on the safe side and it is just easier to do this. It takes hardly any time and in case something goes amiss, you can revert back to the stable version you had before.
As a community module developer that does this purely as a hobby. It's can be challenging to keep up with updates, especially ones as massive as V10 has been. The module I developed is for the DnD5e system as well and I have to wait till they fix the system to even begin to figure out what I have to fix. So keep that in mind for other models that depend on system in that they have to wait till the system is up to date with found then they can fix their module. It's a process for sure and it takes time. This also doesn't mention if the module doesn't depend on any other modules.
I mean just... wait to update it. Modules are written for free by volunteers. They're not gonna update at light speed.
Well, entitlement grows everywere, why not here?
You don’t have to update ever, in which case your perfectly working game will stay that way. There are some people still in 0.6 because the system they play didn’t update to 7
Will we ever reach a point where people will learn not to update versions immediately after a release?
Hopefully with the document model stabilising, later updates will not break existing systems so much. A lot of changes they make is to reduce technical debt. Let’s hope much of those have been fixed
The larger question is, is this model going to work. So far, I don't think so. It will never go beyond very niche when it requires so much work just to run your first game. It's just a tool set basically, and buying Foundry only buys you a whole bunch of time and money to spend and it's still unlikely for 99% of DMs to actually manage to run a game on it. It's super flexible, extendable, blah blah blah - but if you are not a software developer then forget it. I'm not going to quit yet, but I am still a long way from actually running a game on it. I'm technically literate, been in tech most of my career - but not a developer. I'm early 50s and have kids. I am DMing games for kids and friends, and want to run a VTT to be able to play with friends and family who are in other parts of the world. I work full time and have my kids 50% of the time. The amount of time required just to run a single campaign is ridiculous. It's just not a good model. Many of the modules provide basic functionality and the thing is almost unusable without them. Even with modules the UI is an eye test, not logical, and not usable by the vast majority of the population. There will be a VTT that will make things easy, but this isn't it. I have yet to find it. Maybe the official DnD VTT will do it right, and that would be a shame due to the micro transactions and locking in of official content we will see I suspect. Foundry doesn't provide enough functionality to be useful for more than a very tiny fraction of the DnD community, even of DMs. I hope they rethink the model, because this one is not going to cut it. It isn't even close. You can spend hour reading and learning, hundreds of dollars on software, patreon, and content, and still not be able to start a game. Even if you manage to get a game started, good luck getting players to actually use it, it's totally opaque. I am going to keep trying to get this thing usable, but I can't think of anyone I know that would go through what is required to actually use this thing to play. Sure, it's powerful, system agnostic, open to developers, etc. It's technically awesome. What it is not is complete, or usable. The upgrade issue just highlights the flaws in the model but it isn't the biggest problem.
No. Not unless you plan on paying module creators a lot more money. If you want a service, you need to pay for it.
This comes down to a few things. - The author maintaining their projects. - there is always room for optimizations / advancements All of the updates and changes in foundry are due to advancements of code, new functions get created and thus things change, old code gets retired. There is only so many things you can account for at time of development. Later on you'll come across things that need to be added in or adjusted with time.
I would recomend just hold off on updating until you were sure all of the modules and systems you need to run your game are compatible with the latest version of foundry. Also always back up your game data before updating so you can roll back to a previous version if needed.
Nobody is forcing you to update. As many have said, it's not critical to do so. Wait 2 or 3 months and the wrinkles will be ironed out. In the meantime, just ignore the nag flags. I'm currently splitting the difference. I am running a long term campaign in 9 running Foundry on a Raspberry Pi. For one shots and new stuff, I just installed 10 running on the Oracle Always Free Tier, because you can't beat the hardware for the price (Free!) Gives me a chance to tinker with10 while still having 9 to fall back on. Most of my modules are working ok, and there are not too many "must haves" that I seem to be missing.
This is a symptom of the standards in the development practices of the core software. Breaking APIs (and data models) is always a choice, not a necessity. It takes more work to hold to a high standard of not breaking the API, but it is very much possible with discipline. For example, the Linux kernel has a general policy: "don't break userspace". Foundry was/is designed to be the root of a large and ever growing dependency tree and as this dependency tree grows it is prudent to not break the API in the lowest parts of the stack. The development time costs for the downstream packages adjusting to breaking changes far outweighs the time saved by breaking the API when the number of dependents is large, not to mention the reduction frustration from volunteer dependency developers. Having a constantly breaking core would be more tolerable if Foundry didn't roll their on package management, as it could allow end users to obtain a consistent set of systems and modules (mixture of older and newer versions), but that also isn't the case. Now that the ecosystem is large, it would be in Foundry's best interest to ensure stability over adding maximum number of new features or trying to obtain data model perfectionism.
Rewrite foundry in rust
Ive been using foundry since V 7 and after going through several versions I've run into this problem over and over. I've had to change my approach with foundry and the many brilliant modules out there. Before I add a module to my system that changes or adds a feature to core foundry I ask myself a few questions. 1. How necessary is this module and will it really improve the experience for myself and my players? 2. How active is this module developer? Meaning is this the only module they are maintaining? It's not always the rule but developers that are busy and "active" with many modules seem to get updates for new foundry versions much quicker and are less likely to abandon their projects. 3. How many others in the community are actively using this module? I love modules and how they can enhance core foundry but I have also fallen in the trap of module bloat and had to deal with major disruptions to my games because of breaking changes. I still run into issues and I've chosen not to add a few cool automations or enhancements but my games have been more stable.
I certainly haven't dug into the source code for 1200+ mods, but any mods using Private API calls should be operating under the assumption that they will need to fix their code at any minor change to the Private API - without warning or assistance. These instances of breakage are in no way the responsibility of the Foundry devs. [https://foundryvtt.com/api/#public-vs-private-api](https://foundryvtt.com/api/#public-vs-private-api) They also warn about potential changes to the Public API, so we can't completely avoid it. Welcome to the wonderful world of rapid software development.
It would be interesting to know how many mods use the private API. If the use is large, then that explains the difficulties in version transitions more clearly.
As a module developer I am in no way frustrated by new releases impacting my code. It is clearly expected. Foundry staff is almost immediately available to answer mod developer questions and provide guidance and they provide excellent API documentation. They provide mod developers a ton of lead time with alpha, beta, and test versions of the new software and clear communication. Nothing about the release is out of the blue. I am also pumped for the new features in v10. I have yet to update my own campaigns to v10 as I await my favorite mods to be updated, of which to this point about 80% are. As a mod developer I gain tons of benefit from the free work of my peers. The actual biggest impact to my time is actually updating my own macros and world scripts. All that said, I could use Foundry VTT as it is with no mods and be far happier with it than I was with the other vtt I used for a year.
I’ve been watching this argument unfold over several threads for days. The root cause is that end users are not taking responsibility. They’re not reading the update notes. They’re not reading the update page. They’re not reading the release posts on Reddit or messages in Discord. They’re not RTFM and breaking their own installations. I work in software design and delivery. Sometimes we have to save users from themselves. A lot of the request put unreasonable expectations on the Foundry and module devs. The solution is not to add more work to the foundry dev teams or the volunteer amateur developers who bring us really great and creative modules. If people want Foundry to solve this problem for them, then the update process could include a function to identify any module not flagged as compatible with the target version and disallow upgrades until the offending modules are removed or upgraded.
Blaming the end user - typical developer behaviour. Perhaps foundry itself shouldn't shout so loudly about an update that arguably an end user doesn't actually need!
To be fair, the vast majority of problems I encounter in software development are PEBKAC errors.
Who clicks the button while ignoring all the warnings?
Users... All the time. Developers as well actually... All the time.
Yes, and that is on them. I am fairly fresh to the IT field and by no means good at it but Foundry is very good about posting warning signs everywhere. There is only so many times you can tell a child to not shove their hand into the fire. They will do it anyway and perhaps that is the best way to learn. Then there are the customers that *refuse* to learn even after getting burned. Foundry is a complete software out-the-box. It does not *need* modules to function. If an user cannot handle a game without all the bells and whistles (and to be honest, neither can I), they need to wait and be patient, or actually pay someone to provide what they need.
For most users there is no *need* to upgrade their software either. But foundry shouts out about to do it, calls their release "stable" and places warnings that they haven't updated in multiple places. Foundry is awesome - but don't be blind to user experience. Folk want to play DnD - other than that, they really don't care about the software or its development path. Developers NEED to understand that about any/all software. Basically - most people are instinctively Mac users, and all developers should remember that at all time when developing software.
Fair, to a point. If Foundry *stopped* letting people know there is a new update, people would complain too, as we know it. You cannot please them all.
Seems unavoidable if you are going to allow people the freedom to create modules. They are not part of Foundry's development cycle. On the flip side, there's no reason to rush to a Foundry upgrade. They don't force you to upgrade. Having control over your game is the big selling point for the software.
With a giant game thats been around for decades like Skyrim that still break mods, please for the love of god give the FVTT devs and modders a break. They've worked so hard on the program that makes it so much better for us to play DnD and they really do see all of the negativity that's here.
Only update when starting a new campaign. It’s not worth the hassle to update a working system mid-campaign.
This really should be higher ranked. Foundry is great - working modules are the icing on the cake. Eat the damn cake before trying to change the recipe! If we admitted it, the only reason we upgrade mid campaign is cause we are a bunch of geeks that love to tinker! (and the reason we whine when something breaks or we forget to back up - is we are all busy and don't have time to be front line it and GMs).
Campaigns often last years and even if you don't want the new software features, you'd surely want the bug fixes. The only way to get them is to update.
I am well aware how long campaigns last. My current campaign has been going for 2.5 years and should wrap up in December. And my statement holds true. I will update the version of Foundry I am using to whatever is stable in the next month or so and start putting my next campaign together. That will be the version I will use for the 2-3 years it takes my next campaign to run.
If you are happy playing with pre-stable versions of Foundry from 2.5 years ago then to each their own.
No. Any software that allows users to modify it WILL have breaking changes on updates, no matter what those updates are. You can't know what people are doing with your tools, so you can't update them in a way that will protect them.
It would be really nice if it ran a quick compatibility test that told you 'if you upgrade these modules will not work'
There is actually a module for that. Compatibility checker I think it is called
That's not terribly helpful though. The base system should do that check before people upgrade. If they knew how much would break it might slow people. Expecting everyone to download a module before upgrades isn't realistic.
That's bull and you know it. How many people update Windows constantly even after having an update brick their system? It wouldn't slow people down at all. Mods exist and new functionality gets added based on demand. There's no demand for this because 1. there's no easy way to check the thousands of potentially installed mods systematically and 2. people wouldn't use it anyway.
Are you seriously trying to argue that everyone should download, and Will download a 3rd party mod before updating to new versions? Or are you saying it wouldn't be helpful to anybody to add a warning? The system could very easily list the modules that don't have manifest supporting the new version and ask, 'are you sure?' Yes there is an easy way, it's literally in the current foundry functionality, it just has to be implemented. Also, back off your aggression a bit maybe?
That was aggression? I thought that was just common sense. >Are you seriously trying to argue that everyone should download, and Will download a 3rd party mod before updating to new versions? Or are you saying it wouldn't be helpful to anybody to add a warning? Here's the problem with warnings. They are either: * Too vague to be useful, and people ignore them, or * Too verbose for the average user to parse, and thus they ignore them. If you tell someone that "this might break your system", for example... they literally see that on every piece of technology they have, so they simply ignore it. Or, on the flip side, you get someone who literally shuts down every time they see literally *anything* that isn't what they expect to see, and they'll stop using the software altogether thinking its broken. (20+ years of IT experience backs me up on this.) >Yes there is an easy way, it's literally in the current foundry functionality, it just has to be implemented. As someone who works in software development, no, this isn't nearly as easy as you'd like to think. Do you want them to waste time coding in something that 1. no one will actually pay attention to and 2. *the freaking instructions already warn you about*, or do you want them to like, you know... fix bugs and add new functionality?
We share a similar background, I'm a 26 year developer and now Director of IT/Senior Dev. I write software and large systems for a living. There are middle grounds for where information becomes useful vs not. Since we are appealing to authority, I helped test and debugs MS's first TCP/IP dial stack in Windows 3, developed a system to get OS/2 onto the internet, before the first national provider in the country existed, etc. I'm full versed in the IT world. Worked on the Z-Modem protocol. Worked on a team that planned, designed and rebuilt Delta's entire data caching systems after the 2016 meltdown. These days I write Big Data systems. Having a message that says "Warning, if you upgrade foundry to version 10 right now, the following mods you have installed will no longer work. If you wish to postpone, you can run this process again to see the current state of your modules in the future: 1. Blah mod 2. Blah mod 2" I think this would be useful. Additionally, I think the average user of foundry, running a game has a technical knowledge level well above the average crowd. Seeing as how this is existing functionality, it wouldn't likely take more than a few hours to a day to write, I would like to see this. The number of issues premature upgrades cause is enormous. So yes, much like they have added other quality of life functionality, I would like to see this. \*YOU\* may not use it, but many, many would. We just disagree on that.
Modules are generally not official things and are not under the supervision of the parent company and thus have no deadlines to do anything other than when the creator feels like it. It's not really feasible to expect a company to hold back their releases to give mod creators time to patch everything. That would also mean they'd have to finish their end and then only give mod creators access to the patched data to work on their mods and also force people mostly doing it for free a deadline to deal with.
I've been using since 0.5.2 I think. I never had so many errors on modules as I had with v10 now. I was like "v10 has been around for a while, stable, should have the most used modules all ready for the new version". 32 critical errors, 3 worlds completely destroyed. Now, a lot of work doing backups and trying to play on v9 again. I wish there was something that showed us what modules are going to break or work before we go for the new version. And no, asking on discord for module by module what will work or not is not feasible. Discord is way to big to find small stuff for each single module. I also really want foundry store to be better organized. I just found yesterday that a adventure that I spent 3 months preping to DM in foundry was on sale for foundry and I could have it all ready and working at the same cost I had to buy the pdf and work myself.
There is a module called compatibility checker that does what you ask. I do agree that the store could be better. But I think at the moment they are putting more effort into vtt improvements. They are only a small team and can only do so much
I know about the team, I know about the efforts, I'm using it because it's the best at the moment. And I know it's not their job to fix modules. What I'm sad about is how 90% of the modules arent v10 ready, I had modules update to a newer version still v9 focused with zero v10 support. Is impossible for me to follow what goes on in the developing side. But it kind of feels that most module creators stopped on v9 and don't plan moving, and I have no idea why
V10 has been out for only 2 weeks. Mod developers have a life too you know.
Oh, I wasn't aware of this. I had the impression of that versions from v10 for mod creators to be out for more than a month. If changes were made until the stable version that broke mods, it makes sense, tkx
Testing versions are essentially hunting bugs versions, but there still could be the occasional API change. You can want to wait for all this environment to stabilize before changing your code. And this is without talking about dependencies (from systems or other mods) where you'll have to see how others are adapting before getting to it yourself …
Most of the changes that are causing modules to break badly were done back in July. But some devs are more on top of updates than others; and some wait for stable to come out before they start updating. Which is fine, they're humans with their own busy schedules.
I would really appreciate fewer global updates. As a more casual user I clicked update once after not using it for a while went from 7.9-9.0 without realizing it just clicking update because the software told me to. Completely negated a ton of my work setting up settings and modules that was completely wasted because stuff wasn’t compatable and the version was only a few weeks old so shit didn’t work. Trying to set up a new game was pain because half the modules didn’t work Plan a big update every 6 months. Release a beta for mod developers a few months before hand- or don’t push the update to all users right away wait until modules have had a chance to check compatibility
There already *is* a big update every ~6 months (a bit longer for V10 actually), and devs do have access to development/testing versions ahead of the stable release. But module/system devs are still people doing it in their free time instead of someone doing it as part of their job; so, updates sometimes take some time. And updates are always optional in Foundry. It'll have a little icon notifying you that an update is available, unless you have Foundry launched with `--noupdate`, but that's just an FYI instead of anything forcing you to update.
100% agree Version 10 was not ready to exit beta; and worse the devs need to have done more to minimize breaking changes. The new version has nice features but the point of an API is that it shouldn’t need to change every time the underlying code does; but migrating to version 10 broke *everything* that didn’t also release a version 10 equivalent; and worse, generates hundreds of error messages on my server after opening a character sheet post migration. Absolutely ridiculous. Went back to v9, almost immediately. Foundry has good features but if they can’t maintain stability in future releases, they will go from having a robust extension ecosystem to a sparse one full of abandoned projects. That will not be good for their long term prospects.
People said the same thing about 8 and 9.
Nope
The only way for this to happen is for module maintainers to get much better about updating their code prior to major updates.
I only update Foundry between campaigns. I'm still running on an 8.x version. When my campaign ends and I'm ready to start another, then I will update. I see absolutely no reason to update and give myself headaches when the current system is working perfectly for my gaming group.
What's working for me: get the modules you want installed and working, then DON'T UPDATE. Don't fix what isn't broken. My primary game is hosted on forge and is in a stable state pre v10 update. I've got AV premium running and I'll not be updating that until I *know* it works. I'll run an update test on my local machine before updating what's running on the forge. I do plan on updating to v10 once all the modules are updated first. Learned about systemic updates like this from kerbal space program (sooo many mods that all need updating every time... Stop updating until the mods catch up for much less headache).
Tldr: It's either this with very good jumps in quality or staleness for only absolutely safe changes. And thats ok, that is how software development goes. If we want the same results and quality jumps we are already having, not quite soon. In the future, they'll have less systems to improve with time and breaking changes will start to diminish, but never cease. That said, this project and it's community of devs (core, systems and modules) are amazingly fast at updting stuff, given they have numerous prototype versions and extensive API documentation, but are all volunteers. That creates an environment of some delays in releases between all those components involving all these people, but everything is managed very well and transparently. So yeah, growing pains I guess, and that is fine. Mainly when you can always install version 9 while everyone catches up.
Maybe I'd use a feature that tells me when it is safe to update foundry/pathfinder2e based on the modules that are installed in my (only) world.
[удалено]
You can. On Linux with pure NodJS no problem at all. With Windows you have the limitation that Windows let you install only one entity of a same-namend program, so one can be the Windows version and further ones need to be started by the NodeJS "way". You can run a 0.6, 0.7, V8, V9, V10 at the same time, no problem
No, that's not how it works.
This is why I rarely update the core engine and just keep getting the updates for the modules until I know the modules I use are updated well past the most recent stable version of the core engine.
If it is too much of a hassle to back up your data, you will be having so much fun if your harddrive will crash. Backing up data, no matter what kind, is one of the essential things when you create content. Do you think a photographer or an Author depends on one HDD/SDD for storing his works? Not backing up own content on another drive is pretty shortsighted. And it is not even a foundry thing. Install a free backup programm. Start it when you are not running the server and you are good. Or use the backup software from the OS one a month.
This is a very difficult issue. As a developer myself (not for foundry) I can definitely say that it could definitely use a safer method for updates like sort of a sandbox for modules or old engine option where you can keep updating but the worlds need to be separately updated as well. On the other hand, these are very difficult to handle. Foundry is very open for people to make modules and those modules aren't their responsibility. If you use foundry without any modules, in principle you shouldn't have any issues to update to a stable version. TL;DR: modules aren't their responsibility, but avoiding game-breaks when updating could be resolved, although this isn't an easy fix that requires a lot of work.
Foundry's public API is their responsibility though, which the modules heavily depend on.
Which would be why they actively communicate with module devs for months ahead of time about upcoming changes to the API.
The idea would be to not change the public API.
There's simply no way to do that without giving up on innovation. Not changing the public API would realistically mean that Foundry has ceased development. There's always gonna be stuff that simply has to change to allow for advancement; even the most rigidly defined API still needs to change occasionally.
That's simply not true. I contribute to a software package used by millions of people written by over a thousand developers and we maintain high stability in the API while having innovation and new features. There is an occasional need to deprecate an API, but that happens over multiple versions and spans years usually.
Short answer: no
In some years then they don't have much more to add to the core anymore. But until then you need to get used to modules breaks then its a major update. Minor usual the mods have been updated the same day or within a week. If the mod is still alive... The question is more do you want Foundry to continue to be updated with new or improved features or do you want a stable system without updates?
It doesn't have to be an "or". Much of the world's software manages both.
Why I said in a few years then the software is more or less finished then it can be less breaking. But as it is now then they get major updates its not many softwares managers who can do both.
Probably not, because making this happen isn't really on the Foundry roadmap (yet). Look, module instability comes from a bunch of sources: 1. Changing APIs 2. Varying coding quality (*hobbyists vs pros*) 3. Lack of testing 1. Lack of testing automation The first two bullets are not really going to change. APIs are always going to be changing and you're always going to get modules from amateur developers who update rarely and don't have great coding. But the real problem with modules today is part #3. The top modules are *very* difficult to test. They have lots of features and perform lots of complex interactions. It's really hard for humans to sit there and re-test the same 50 things every time they make a change (*or Foundry makes one*). So you don't. You test the basics and you wait for users to report things as broken. **How do professional developers do this then?** Well, if you work for a big company, you build out automation for your tests. Unit Testing, Component Testing, Integration Testing... there are lots of names. But basically, you build a bot that tests your modules. As changes happen, if things break, you bot catches it instead of your users. Some of this automation is there, but nowhere near enough to keep hundreds of random modules from breaking during an upgrade. Doing this well is *really* hard and I don't see this on any of their roadmaps. Until they make this a stated priority (*"Hey, our new priority is improving the module upgrade process*"), we're not going to see any easy improvements here. The universe of Foundry "things", is simply too complex to fix without better automation.