Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

Version 12 Feature Vote (Patreon)

Published:
2023-06-16 16:29:21
Edited:
2023-07-17 22:45:49
Imported:
2026-06
Tags:

Poll

Version 12 Feature Vote

  • Advanced Measured Templates 279
  • Dynamic Soundscapes 72
  • Environmental Animation Effects 127
  • Event Triggers 320
  • Improved Fog of War 200
  • Placeable Items 242
  • Scene Types and Transitions 165
  • Terrain and Cover 319
  • 2023-06-16
  • —2023-07-15
  • 1724 votes
{'title': 'Version 12 Feature Vote', 'choices': [{'text': 'Advanced Measured Templates', 'votes': 279}, {'text': 'Dynamic Soundscapes', 'votes': 72}, {'text': 'Environmental Animation Effects', 'votes': 127}, {'text': 'Event Triggers', 'votes': 320}, {'text': 'Improved Fog of War', 'votes': 200}, {'text': 'Placeable Items', 'votes': 242}, {'text': 'Scene Types and Transitions', 'votes': 165}, {'text': 'Terrain and Cover', 'votes': 319}], 'closes_at': datetime.datetime(2023, 7, 15, 3, 59, tzinfo=datetime.timezone.utc), 'created_at': datetime.datetime(2023, 6, 16, 15, 52, 20, tzinfo=datetime.timezone.utc), 'description': None, 'allow_multiple': False, 'total_votes': 1724}

Content

Thank you all so much for being part of our Patreon supporter community. Your continued support and encouragement means a great deal to our team.

We hope you are enjoying access to the Crucible Playtest - it's been really thrilling to receive such enthusiastic feedback from the community for that project so far.

The time has come to solicit your input to help define our priorities for Foundry Virtual Tabletop Version 12. Only Patreon members are allowed to vote in this poll.

Poll Rules

We are changing the process of the Version 12 Feature Prioritization vote this time. We regret that Patreon does not offer support for ranked choice voting, and we understand the frustration that the prior implementations of our poll allowing each user a single vote create some adverse voting incentives. For the Version 12 feature vote we are going to experiment with a multiple-choice poll which allows you to vote for as many options as you wish. Please cast a vote for any options which are ones you would be happy to see prioritized in Foundry Virtual Tabletop version 12.

The winning feature will be the one which obtains the most votes overall by the time the poll closes.

The poll will remain open until Friday, July 14 at 11:59pm Eastern Time.

Poll Options

While the poll is only open to Patreon members, we want to share details about the options and our plans with our entire community. Please read the following article for a description of each feature offered in the poll as well as some news about plans we have for Version 11 improvements before we begin work on Version 12.

https://foundryvtt.com/article/v12-patreon-vote/

The choices are listed alphabetically below. Details about what each would entail are provided in the article linked above. Please vote for any features which you would be excited to see added to Foundry Virtual Tabletop Version 12.

We encourage all of you to join the discussion about this vote and share your thoughts in the comment section of this poll or in the #v12-patreon-vote channel of our official Discord server (https://discord.gg/foundryvtt).

Files

Comments

thetreat

Is tablet improvement not an option? It was in the v11 poll and was a highly requested feature.

Tyler Robinson

I'd like to see better drawing tools. When you draw a line, it becomes a huge selectable box. Draw another line over top... and good luck trying to select the one you want. It desperately needs improvement.

foundryvtt

I expect this to be a frequently asked question, so hopefully this helps: Regarding "Tablet Support". The reason this option does not appear in the vote this time around is that our strategy has changed around how we are approaching this due to the way we have decided to approach our UI framework overhaul that has begun in V11 with the Setup area. This overhaul will be gradually rolled out to the entire software over the course of versions 12, 13, and 14 and will encompass the features needed to support tablet devices. Because we are committed to this path, we cannot deliver "tablet support" in V12 regardless of community preference, but equally so it's something we're actively working on via the UI framework updates that are already part of our committed roadmap.

MTVExtreme

I'm curious, is the Standalone Player Client no longer an improvement you're looking into for this update? Is it perhaps planned as a choice still for the future (Saw your reply about Tablet support). I know my players and I were much looking forward to that feature in particular since we've been struggling with performance issues in-browser since V8 released.

M0nk3yy

A standalone player client would really just be a browser with no add-ons and extensions, so in my opinion is not a great use of development time and effort. If they really want to use a dedicated client, there are some great 3rd party ones like "Foundry Lightweight Client".

Shayulghul

I want to vote for all of these, but I'll restrain myself to my top picks lol. Keep up the great work!

Ric V

These are cool, could you add to the templates the ability to add a volume template, where you target a point and like liquid or smoke it fulls a specific volume? I have run games with this kind of mechanic for like blast templates and it definatly adds a cool dynamic

Andrew

+1 - we use a couple tablets at my table and the experience can be a little frustrating since you pretty much need a mouse wheel to zoom in and out (at least in v10, I haven't upgraded to v11 yet).

Andrew

Since a client would just be a stripped-down browser, performance issues are almost always due to inadequate hardware (which a client can't help with), overstuffed scenes (which a client can't help with), or your browser arbitrarily deciding to use integrated graphics (which a client might help prevent, but can also be remedied with a browser setting change). If it's not the latter cause, a hypothetical client won't help.

Ryan Rogers

Looking at the early votes, it already seems that Event Triggers won't happen, again, because the new shiny jingling keys are getting all the attention, again. :-( Such a bummer that we still have to rely on 3rd party module for a fundamental feature that actually makes a huge difference in gameplay and is massively enabling of downstream capabilities. Macros and scripting are a fundamental powerhouse that is neutered without events and triggers in Core. The Core Product has a V8, but only 6 cylinders are firing without this. In fact, I argue that this is such a pivotal missing feature from Core, I honestly don't even see why it's up for Vote. I think the executive Product Ownership decision should be made to Just Do It, Nike style. Not necessarily for V12 if there's no room, but get it in the Roadmap and stop letting the community decide, because the Community will often vote for what's shiny, especially if they already have MATT integrated. In short: they'll vote what's good for THEM, but not necessarily what's good for the PRODUCT. New customers haven't heard of MATT. They just want to know why they can't do simple, basic things and empower their macros, to, you know, fire when something happens. :-) Just my 2 bits...you know how I voted. :-P

MTVExtreme

Thanks for both of your respectful thoughts and opinions. While I'm a developer (just not for Foundry) I unsure of the overall impact it would have on performance since I'm not developing for the platform. Thanks for pointing me to FLC, i'll check it out and see for myself. I was also wanting the standalone for the other features they mentioned, like discord integration, and local character storage that they mentioned in the V11 poll.

Brendan McCoy

I just want Fog of War parity with Roll20, in terms of manual management. The particular use case I want supported is manually clearing individual hex maps, the current modules available don't cleanly support the flow of.... click a hex, reveal a hex. There's always some jank or non-clean revealing that happens.

Majoros Gergely

One of the things I miss from the VTTs is that there should be some solution to the problem of characters and opponents' tokens blocking vision, so that you can't see through them. As if there really is a body blocking the vision. But all this so that the token, the image itself, is visible to everyone in the same way, just not allowing the things behind it to be seen. It can be useful for similar items, objects in the sense that you want to see what that particular thing is. For example, in the case of a column, see the column itself, not just the blockage. If there is a solution to this, please excuse my ignorance. I have little experience in Foundry.

OpenFantasyMap (edited)

Comment edits

2026-09-28 01:00 I love foundry for most of its aspects, but I think a major work in the aspects of character management is important. The master cannot have the same view as the general player, needing to have all parameters under control.
2023-06-16 18:00

foundryvtt

I don't disagree with you that there is a big opportunity to improve there, but we need to limit these feature votes to improvements that we can make in the core software. Improving the UI/UX of character management is highly dependant on the individual game system to implement the workflows and interface that is right for them. We can't do that work on their behalf so it wouldn't be possible to put something like that in this poll.

foundryvtt

If it's any reassurance - Event Triggers is a missing feature that I feel VERY strongly about adding to Foundry VTT. It's absolutely going to happen at some point whether it wins a vote like this or not, but we haven't been able to prioritize it *yet*. In case you're not aware, every time we release a new software generation we include 3 main features: 1 voted on by the community, 1 "under the hood" infrastructural improvement, and feature that we think is most important. There is plenty of scope for Event Triggers to be developed at some point (whether or not it's V12) even if it doesn't end up winning this vote. That being said, it certainly gets MY vote!

Nick Scott

FWIW, it's been my top vote for the past several polls too. I just see so much time saving potential and less fiddling I'd have to do in the moment as GM. Who doesn't want to ease their burden as GM in some way? One less plate to spin would be appreciated.

Steven Pine

v11 broke the touchvtt module unfortunately which provided decent access for tablets.

Gage Eakins

Oh I never knew local character stories was on the table for the standalone client. I think they should have made that highlighted a bit more. I would have actually voted for it had I known that. As others have mentioned the performance improvements via standalone client for players would be minimal due to the way foundry works. That is why I didn't vote for it in the last poll.

Robert Revesz

Better support for fog of war for hex crawls would be great

Gage Eakins

Honestly the reason I don't vote for event triggers is it's just another feature that requires more work from me. I don't really use the third party modules like monks tile triggers for the same reason. I would rather have more fundamental concepts covered that don't just simply increase more work for me to do.

Gage Eakins

You know I imagine that wouldn't be that difficult for a module developer to add. Essentially it would just need to create terrain walls around the token and move them as the token moves. That probably isn't the best way to handle it but the only way without a better course support function.

Marco Montanari
>>110874228

totally agree, as a software developer i know focus is the most precious value. i just wanted to point this out, for the future. maybe also for myself, as it would be something good for a module

Kristian's Foundry VTT Modules

For Tokens, no there isn't an existing solution, but IMO, in combat, characters and opponents are just standing still. They're moving around, ducking, dodging, lunging, etc., so they're not exactly blocking vision past them. For objects, see Terrain Walls in the walls layer of core Foundry.

MWGaming (edited)

Comment edits

2026-09-28 01:00 Is there a preferred path to develop things in this list? (Or does it not matter what order features are developed? )
2023-06-16 19:32

foundryvtt

There are some relationships between features and there could be some minor efficiency gains if we worked on these in a certain optimal order, but I think those gains are relatively minor. Part of the reason we came up with *this* list for the vote is that this is a set of features that we could do any of these next without it being overly inconvenient.

Anile_000
>>110880865

like "Event Triggers" I could see being a platform upon which parts of Terrain effect or Interactive objects (at least, "open", "investigate", "pick up") could be good to build from. And I'd guess that NEDB shift might have made some of the work in adventure or previous handling of documents in a world if not simplified, at least less work to optimize/make work again.

Lee Fuller

Far be it from me to disagree with our fearless leader on matters concerning the core support for features. However, something that we all must consider is the very fact that a "potential feature list" implies that there are only so many resources available at any given time to "upgrade" or "add" feature sets to the core product. That said, when a 3rd party builds a module, they tend to do so with more available time to not only create but also enhance that module with much more feature-rich capabilities - which frankly would take up way too much time for the core development team. In short, sometimes 3rd party modules can do more, quicker, than core inclusions. Over time, of course, these "add-on" features can be added to the core product. Yet, the initial implementation of these features (already supported by a 3rd party module) will likely be somewhat of a step backward from the module version - at least until the core developers can fully build out the functionality. Just my .02.

Gaëtan Perrault

As noted by @Robert Revesz, a third-party has created basically this thing. But the bigger challenge with the "standalone client" is that people expect it to somehow "perform better". But that's not really a thing. The thing about Foundry is that it *needs* a mid-range computer for almost anything it does. Unless your DM is running with very basic modules and super-compressed maps and no lighting effects,... the system doesn't work on lower-end devices. A lot of requests for "running on a tablet" kind of run into the same issue. When people say "running on a tablet", they are not typically talking about running on a 10th gen iPad (2022). They're talking about running on the tablet they got 4 years ago as a signup gift with their mobile phone plan. And like, that thing isn't going to run very well if it's facing down a large dynamically lit dungeon.

Gaëtan Perrault

Frankly, a lot of this stuff is already covered by modules that are freely available and supported by various creators. The current leader is "Terrain and Cover", but Levels already does a bunch of this and more. It doesn't support "difficult" terrain, but Foundry doesn't support movement limiting anyways. Can you talk to TheRipper here? "Placeable Items" may actually benefit from support at the Foundry level. But most systems can already leverage things like ItemPile. In fact, I'm not sure whey you want to develop and support this? Why not just talk to WASP? "Event Triggers" sounds great. But already have MATT. What are you building that Monk hasn't already created? In fact, it sounds like you're doing less than MATT currently does? I could rinse and repeat this argument for basically every item on that list. We already have modules for these, but you don't even acknowledge them. Some of them may be marginally improved by being in the Core, but that just means you're going to destroy someone's module and make upgrading a pain. I think every item on this list needs a better plan.

Unomagan

Version 13 should add: Stabilizing API for modules. AKA: Put more thoughts into the general and used APIs. And redesign where needed, this might break more modules, but should stabilize future versions... I think everyone would agree that this would be useful...

Ryan Rogers

@Gage Eakins I would argue that having macros without the ability to trigger them with something as simple as token movement is a pretty "fundamental concept" in the scope of what this product already offers. Sure, other VTT's don't offer event triggers...but those aren't scriptable and don't have macro support. To use another analogy: We have the basketball, but no hoop. We have the baseball...but no bat. Naturally, many don't want to play sports, and that's fine. They don't care that we have an incomplete set of tools. But, many *do*. And those that do, need both to play, and we're sick of asking the neighbor to borrow theirs. :-P @Foundry Gaming It's good to hear it's coming, even if not in v12. Sounds like we're on the same page regarding priorities. I was very aware of the 3:1 ratio of features and how they're determined. I was a bit shocked we got some features in v10 and v11 in that "3" side that weren't Events, especially given what went down with Trigger Happy and the transition to MATT, but these things happen. This is why I think it's important to have the base implementation and API in Core. MATT will still exist, and will be better / leaner / meaner for it. @Lee Fuller I do not disagree, but I do think that discounts one very key point of module development: the requisite foundation. When these new systems are added to Core, they aren't typically added in a vacuum. They expand the API, and in the case of Event Triggers, that would greatly simplify and streamline a future version of MATT. In fact, if you look at most of these features in the list, they're all about building out the API, as should be the case in a system with this architecture. The 3rd party modules (and the fact that there is an open platform to begin with) is the primary reason behind the success and rapid adoption of FVTT. Clearly we agree on that. With that said, as features have been added to Core that had existing modules, it has resulted in better modules with less code to maintain. The FVTT staff has gotten very good at designing API's that make sense and provide a great foundation for refactoring, and thus simplifying, modules after the fact. If I were a module developer, I would welcome the help. :-) Short-term effort for a long-term gain. I have zero doubts that MATT would still exist as it offers features that the Core solution likely will not. Which means, going forward, the module developers can continue to focus on those niche/fringe areas of their offering, thereby adding more choice to the Community that will NEVER be in Core, because of the very nature that it is niche/fringe! Furthermore, the module devs could do so more rapidly, as they would have less code to maintain, and have new API's that let them do new either new things, or existing things more simply, both of which are accelerants to progress. It's a win-win. Not only for the people like me who want to use one less Module, and only need VERY simply events; but also for the people who use every bit of power provided by MATT...and want more. Both can win, including the module developers themselves whose lives will get easier in the long-run. Naturally, not every feature is like this. Let's look at another example: Pings. By your reasoning (if I'm interpreting correctly), adding Pings to Core was a waste of time, because we already had the Pings module. You may believe that, and that's fine, but I am one of MANY (and I'd dare say MOST) customers are VERY happy to have One Less Module, and having it been replaced by a VASTLY superior implementation in Core was a boon for us. I'm glad they spent the relatively small amount of time building it.

Ryan Rogers

Some thoughts on the current leader: terrain metadata for difficult terrain and various wall cover. This is very much a 5E / Pathfinder perspective. YMMV at your table. I won't use it. At all. Not because of the additional prep time required, but because of a matter of accuracy. It won't work. Not in my game. Nor are handling multiple cover types or difficult terrain a burden. It's trivial problem that doesn't need a solution (at my table, again, YMMV). The facts (again, of my table): - difficult terrain changes at play time, all the time. Stuff gets moved. Enemies drop. Debris is created. Etc. You aren't going to define metadata for that at runtime, and even if you do, not all enemies create difficult terrain when they drop. Some do. Some don't. And don't even get me started on debris or Animate Objects. The runtime burden is too heavy, and static by itself isn't enough. - in my game, my 6 players have a total of 5 different ways to ignore difficult terrain, and 4 of them are based on some contextual situation that only applies some of the time. Some ignore ice/snow only. Otherwise ignore mud/swamp only, Some ignore all. Some hover over the terrain 1 foot, but only after they've activated a magic item (requires bonus action) which lasts only for 1 minute. Others get it with the Freedom of Movement spell. Is the Measurement Tool which estimates movement going to correctly factor in all of those contexts? Nope. Not a chance. Thus, we can't trust it. Thus, it's may as well not even exist as a feature to us. We will continue to do token movement one square at a time, counting off either 5 or 10 as we do because we as DM's / players know "all the things" that the VTT never, ever will for something this complex. Even with modules. - similarly, -2 / -5 / unhittable for cover is not hard. We don't need that handled with automation. The one we do need, unhittable, we already have and is enough. I get that there are automation nuts out there who love that stuff, and that's great. I used to be one, very early on, but then I saw the light. :-) I don't need an attack to resolve automatically and take into account half or three-quarters cover. Furthermore, if you think it's the lack of cover support that is "holding you back" from achieving full automation, you're likely wrong. When you get this...you will find the next thing. Then the next thing. Then the next thing. Until finally you realize that the ONLY way to achieve 100% accuracy is to ignore automation, and be less like a video game and more like a TTRPG. :-P The point is, there's no way a Core feature is getting that right all of the time. It'll be lucky to get it correct 80% of the time, if that, for systems like PF/PF2/5E. Again, YMMV as your system or your table may not use all of these items/spells/rules. Ours does (and more...variety is the spice of life afterall). Movement and Cover are VERY complex in our game, and Core won't get it right most of the time, even with these features. Perhaps with a bunch of modules it will be close, for stock items and stock spells, but what about homebrew? Hmm? This is my point on automating all the things: If it's not accurate 100% of the time, it's dead to me 100% of the time. It's why I don't use any weapon attack automation, or movement automation that exists today in the various (and great) 3rd party modules, because it can't be trusted. These features will close that gap, and empower them to get closer, but they still won't hit 100% accuracy. And, until it works 100% of the time, we won't be using them. Doing so would result in error, or slowing down the game vs. speeding it up as we "fix" what it just did wrong. Let's look at difficult terrain again...in order to get it right, I have to not only define difficulty regions, I have to tag them with ALL of the relevant metadata possible metadata (off hand I can think of at least a half-dozen types of static difficult terrain), and that doesn't even count all of the runtime versions that can be created. Then, the fact that certain magic items, or certain spells, ignore certain kinds of terrain. Some only for 1 round. Some for 1 minute. Some for 10 minutes, but require Concentration. Ugh. Furthermore, many of these things are not tied to Conditions, so 5E System level can't handle it either. There is no "Condition" that says you ignore difficult terrain. There are class features. Or spells. Or magic items. Some permanent. Some ephemeral. It's the ephemeral ones that are the bitch, but if you don't handle them, the automation is broke. I will say this though...if this is added Crymic is gonna have his hands full trying to make all of this work. Full time job that I wouldn't wish upon anybody lol. So, yeah, I get that in *theory* the feature sounds cool, and in *some* tables it may work great. But, for 5E and for Pathfinder 2, given their stock magic items and spells that affect terrain difficult and cover, I just don't see the value without going ALL IN on third party automation modules to try to wrangle all of this in and make it work, and even if you do, I 100% guarantee you won't get it right all of the time, especially once you factor in Homebrew. I've created over 500 Homebrew spells and magic items, and probably 25 to 30 deal with cover or terrain. Even if Cyrmic and his helpers get all of this working...it won't work for those without additional work from me. I won't do that work, because I know better. I know even if I do, I can't trust this all to be accurate 100% of the time, so I use it 0% of the time. So, yeah, even if somebody gets Ranger and Sharpshooter and Freedom of Movement and Boots of the Winterlands all working (and that's the literal tip of the iceberg)...what about the dozens of Griffon's Saddlebag items that affect these? Or the dozens I've created? Or the hundreds on D&D Beyond public Homebrew? And, if you can't get it right all of the time, my take is you shouldn't use it any of the time. But that's just me. Clearly not everybody has the same opinion, otherwise automation wouldn't be such a Hot Topic. :-) Early on in the FVTT days I was an automation junkie, but I have since seen the light. :-) Again, just my 2 bits about my table. I'm sure there are automation nuts out there who have embraced it whole hog, and for them, having this will improve their accuracy of their games and simplify them. But for me, it'll go unused, because I ignore this automation stuff because it's a mountain of work to be 90% right.

Andy Donndelinger

I was wondering why the "Touch/Tablet Support" option didn't make it into the list of v12 features seeing how it was almost the winner of the v11 feature vote? Now that life after the pandemic is starting to get back to normal, this feature is even more so needed! My regular group that has been playing for decades found foundry a fantastic option when we all had to stay home, but now that we can meet up, foundry doesn't lend it self to in person games. But this option would allow us to use foundry to its fullest again while allowing us to be in person. Is it possible that we could get that added back to the list of options for the vote?

foundryvtt

Hey Andy, please see my comment on this as a reply to the very first comment on the post. I wish there was a way to link directly to it, but I'm afraid I don't think there is. TL;DR, we're already working on it, but it's going to take some time.

Quirken

@Foundry Gaming It would be cool if Foundry VTT offered some means for 3rd party modules to request "promotion" into core functionality. Since FVTT isn't open source, that wouldn't be as simple as pull requests, but I imagine that the plugin API probably isn't drastically different than the internal workings. (Otherwise, I imagine module development would be a lot more difficult!) For things like event triggers, I imagine it would probably be less work on FVTT's side to "port" from plugin to core than restarting from scratch. It'd be a way to indirectly involve the community with development. I imagine some functionality might get dropped as part of such a "porting" process (since the implication would be that FVTT would maintain it going forward), but the original module developer could likely work around that such that their 3rd party module would just supplement the "core" functionality.

Trashloot

I honestly think that event triggers is a neat power user feature but nothing more. Sure its fun to have the lights go out when a door opens or a bunch of npcs running around spaming random quotes but it is not necessary in any way. It is also way harder and more time inefficient to script something which you can narrate quickly and imagine in your head. When im using Foundry im not trying to build a final fantasy. I will use Mood pictures for most scenes and use Battlemaps for combat. An important hub might get a map as well. And don't get me wrong. It would be greate to have more automation in the hub but i don't have enough time to build the fanciest battle maps every other week and i can't even think of a use case for mood pictures. I would take a feature like (improved) trading between NPCs and Player (or players and other players) over something like triggers because i get much more use out of it, whitout spending a ton of time to set it up.

Trashloot

Why don't you just do it in the old Roll 20 way ? Just fill the hex map with black hex tokens which cover the map. You can then delete the tokens one by one to reveal the hex underneath. I don't know how hard it is performance wise because i haven't run a hex crawl since switching to foundry but it might be worth a try. Because players can't control the tokens it looks like a black map to them.

Trashloot

I would love to see an improvement to the music playback function. - Having the ability to blend music tracks together by crossfading two songs or the beginning and the end of the same track to enable a seemless transition would be great. - It would be awesome to have foundry check the download progress of the tracks for all connected player so that everyone hears the same thing at the same time. (Currently it is possible the the music hasn't started for one player while some other player is hearing music for the last 10 seconds. This makes it impossible to fit the narrative to the music). - It would be awesome to be able to preload audio tracks like you can do with scense. Right click -> prepare playlist - It would be awesome (but probably unrealistic) to have foundry optimize tracks for streaming. It would be cool if you could have an optional feature which could compress / reencode audio to save bandwith.

Trashloot

I don't think its that difficult. You would just need a separate layer where you can draw boxes on to and give them a Movement modifier. When you then meassure distance or drag your token over it you would simply show two numbers. Movement without difficult terrain and Movement with difficult terrain -> "20(10) units". Players could then pick whichever number is applicable to them. I don't need difficult terrain automated. I just want to simply the measurent process when meassuring over certain tiles of difficult terrain. Movement where you only move over difficult terrain is easy. But it gets annoying when you have to count diagonals and a few pieces of difficult terrain.

Ryan Rogers

I agree it could be that simple, and that certainly could be enough for some instances, but to my point is it won't get you to 100%. It's unfortunately not that simple to get to 100% coverage because difficult terrain does not stack for application (crags + snow = 1/2 movement, not 1/4), but you have to overcome both to have normal movement speed. Overcome only one of them, you're still 1/2 movement! So, one number can't work for all cases. It's not one piece of metadata. It's one per type of difficult terrain encountered. Furthermore, the player needs to know what type(s) of difficult terrain it is so that they can make the right call, which means I'm having to explain it anyway as it may not be obvious on the battlemap: - Uneven terrain? - Snow/Ice? - Mud - Debris - Some combination of any of the above? (the real kicker) For example, snow and ice covered crags. They were literally in a recent session of mine. Doubly difficult terrain = just difficult terrain. However, some players have the ability to overcome both (Freedom of Movement), but other players only one (Boots of the Winterlands). So the Ranger still moved through there just fine, but the cleric with the boots...not so much. So it's not just one extra number. It's potentially many, each of which needs to be labeled and identifiable in order to be accurate, which means you've just increased the necessary UI in order to properly support this feature minimum three-fold (which also means it's harder to learn and use), as it's no longer "just a simple box on a layer". You've also complicated the UX greatly, as you have to have a way to convey these simultaneously to the player using the tool. Or, you as a Product designer you ignore this complexity, keep it simple, and accept it doesn't cover all cases. 80/20 rule. This is what I'd do...which is EXACTLY my point...I'll NOT USE THE FEATURE because it isn't likely to cover the cases that I, as a DM, can by handling them myself. :-) It needs, at a minimum, support a variable amount of metadata per region for a potentially overlapping area of regions. If it's going to model what actually happens in games, it needs to do at least that. I think that would make it very difficult to use. Again, 80/20 rule. So I 100% agree with you. It *should* be that simple to learn and use. My point is IF it is that simple, it won't cover 100% of cases. So, I won't use it. As such, the simplest solution for me is to pretend it doesn't exist. I already cover 100% of the cases. :-P So instead, I would continue to handle it the way I handle it: as tokens move, count off 5 or 10 at a time, because as GM I know where it's difficult or not, and I know if their token has a way to overcome whatever difficulty may exist in that particular unit of area, or not.

Ryan Rogers

@Trashloot (Max) I agree it's a power user feature, but I disagree on the examples and the reasoning behind it. Sure, many people ignore macros. They are already a "power user" feature by their definition. The point is, they are popular, and without something to trigger them, they are less useful. Still useful, but less so. It had never even dawned on my to trigger lights macro based on people entering the room. Or have NPC's banter. I guess you could do that...I wouldn't. I 100% agree, this isn't video game recreation. While triggers do let you do that, that's hardly their only use, or even a good one. I think those are terrible examples, and I don't use triggers that way. I think a far more useful example are traps triggered based on movement, such as covered pit trip where floor disappears on entering, and you hear a scream and crashing debris sound, and token movement is captured. That's a whopping 5 line macro in my suite called WilhelmPitTrap01. :-P It was one of the first macros I wrote, took all of about 10 minutes with help in #macro-polo. I've used it DOZENS of times. It's gotten DOZENS of laughs. I've since created more popular variant wrapper macros which all use an internal macro. Spear traps. Saw traps. Tilting floor traps. Pit traps. Crashing log traps. You can do SOOOO much by simply: - hiding an image - showing an image - playing a sound - capturing the token (to prevent additional movement as they are "trapped") Foundry Core, today, gives you ALL THE TOYS you need to write that macro or macros. It's actually really simple to do. But, it gives you NO WAY to hook it to a simple area so that when it is entered by a token, it fires for that token, and clamps it down. As a GM, I want the VTT to handle that token capture for me. Even if I don't play the sounds or all that jazz, I want where the trap lies, to be triggered, so that it is not overlooked or forgotten, and actually "traps" the token in the...trap. I just embellished mine for laughs, and laughs it gets. :-P So, yes, definitely a "power user" feature, but one that we already can 95% do in Core. We're missing the tiny last little bit, but it's a HUGELY important bit. That's the point. That's why it's such a clutch thing that is needed. The other way I look at it is there are people out there right who ARE USING macros in a far more complicated fashion that this, but aren't taking this last step to automate them, because they don't want to install a 3rd party module (maybe they got burned with Trigger Happy *cough*)...or don't realize you can. The key is, once it's in Core...there's no longer an excuse. :-)

Brendan McCoy

I just don't think it's a very scalable solution, and I've found some players machines really struggle with scenes with many objects.

Denise Atwood

I would be happy with any of these improvements but the 2 I am most excited for are Scene Types and Terrain and Cover. The others would be cool, but nearly all of them I can do to some extent with a module. It would be great having the options in standard Foundry, but I still have access. But Scene Types would be the thing I use the absolute most. I use animated scenes during TotM moments and the amount of times I forget to change the lighting so that players can actually see it is obnoxious. And also feels really weird to spend so much time going through the options to *remove* the grid and make it so players can see it right out of the box. It's different for battlemaps because I'm probably spending a lot of time on walls and such anyway, so doing the lighting at the same time just makes sense. But if I want to throw up an area map or animated scene, spending minutes making it so everyone can see it really is annoying. Terrain and Cover is something I haven't seen modules for, so I would be super excited for that. My players never seem to be able to track or remember things like that on their own and I've already got a bunch of monsters to handle. It would be great for the VTT to do that

Pyram King

GM SECRETS One thing that has always been a little frustrating is the way the SECRET BLOCK works. If you create text that is secret in an item or journal and the player is then given permission, they can SEE the Secret. This hinders hiding Curse items and other things you do not want the player to know about. There was a simple module called GM SECRETS which made the secret block tied to player role (GM or Player) rather than ownership. It worked in v7 - v9, but with the big changes in v10 it no longer works. https://github.com/kaelad02/gm-secrets/tree/v10changes I would think this should be a core basic feature in Foundry. Making Secret Block text tied to roles rather than permissions. I just thought I would share.

Trashloot

See i don't get your trap example. I would simply play the soundfile with a music bot /soundboard and describe the rest. My description of how the character panicks when he realizes that ground under his feet drop away is way more immersive (in my opinion) then any automatically appearing tile. I would intentionally keep something like this in theater of the mind. Oh and i kinda see why you would want to "freeze" specific tokens but quickly hitting spacebar to pause the game is the better solution for myself. Im not invalidating your points. Just interesting how different we see these examples :D.

Ryan Rogers

I think you are assuming that just because something is automated, that VTT must handle all of it and that Theater of the Mind has no place in any of it. That is not true. Of course I describe the trap, how it falls away (or sprung) out, and how the character is impacted in excruciating detail. It isn't like the trap is dumping text to Chat Log lol. The difference is, when I do it, I don't have to go fumbling around, clicking multiple things, or pressing the Pause (space bar) at EXACTLY the right time (and move the tokens back when I do not). Work smarter. Not harder. I can have all of those things be automated, AND provide an immersive description. They augment one another. It's not either or. In fact, since they are not only automated but triggered, as the GM I don't have to even think about them. I can 100% focus on the descriptions while the party is in Exploration mode...which is when they trigger traps. The fact is, the thing that breaks immersion the most is waiting for the GM to fumble around and do things in VTT clickity clickity. Regardless of how fast or accurate they are, they are not instantaneous. :-) With my way, I can immediately jump into the descriptions. No fumbling. No delays. This is why automation is so crucial, and triggers in particular. Even though FVTT can do tons of stuff, and has tons of features, without both Macros AND Triggers, you as the GM have to "drive" them all the time. And, traps are a perfect example of how Triggered Macros can do ALL of the monotonous heavy lifting, and leave ONLY the theater aspects for the GM at runtime. Win. Win. It's not either / or. It's combing the strengths of both.

Joseph

Seconded

Remy Starshade

Try GM Notes: https://foundryvtt.com/packages/gm-notes I use this one. It doesn't appear inline, but I like that because the player can still edit the item and have no idea there are notes attached to it. The really cool thing is you can add notes to anything, even character sheets (PC and NPC). It's pretty nice. Also, not only does this one work on v10, but I'm using it just fine on v11 :)

Remy Starshade

Uh, MATT was broken on V11 for quite a while. Having it as a core feature means not having to depend on someone who works for free to produce and maintain an important feature.

Dustin Swalley

How about the option to remove "News" and "Featured Content"?

Robert Revesz

No I haven't yet. Thanks for the tip, I will try give it a try.

Robert Revesz

Okay, it seems to work for what I need. Still struggeling to understand what the 2 reveal settings do though.

Tim Haldane

This comment, 100%. From a developer standpoint I completely get the desire to directly integrate the features of popular modules into the core software, especially since it can undoubtedly be accomplished more elegantly and efficiently that way, and undoubtedly creates new hooks for future modding to build upon. But from an end user perspective, it does come across like a lack of creative direction, potentially even a lack of respect for the hard work done by modders. To be clear, I sincerely doubt that is the case - I believe everyone involved is doing what they genuinely believe is best for the software - but it's difficult to vote in an educated way on features if I'm not being told how it builds or improves on existing mods that appear to do the same thing already.

Gaëtan Perrault

Sadly Tim, you and I are in the minority here. The guy who does Placeable Items was totally surprised by this. Even offered up their own MIT code (which Foundry obviously doesn't want). We had a whole thread up on Discord, but it's pretty obvious that Foundry wants to benefit from Mods until they absorb them (to the detriment of everyone using the mods). If they *really* wanted Placeable Items or Active Effects to be both "integrated" and "compatible", they would contract those developers to make this happen. They wouldn't need a vote, just cash on the table. Those contracts are clearly not on offer. So we're just going to get some obviated version of MATT.

foundryvtt

Upon first reading my reaction was "wow, what a clumsy attempt to troll" but upon re-reading I think this is actually a genuine but remarkably bad take. Well done! We love the inventiveness and creativity of our modding community, but that doesn't give them monopoly on ideas any more than developers have to ask our permission to turn their idea into a module. Our desire to implement placeable items (issue #227) dates back to December 2018 and has been an epic-level goal for us to add to the software since the Alpha Patreon playtest. If Placeable Items were to win the poll, we would absolutely discuss and engage with Wasp or other developers who are active in the space, but seeking permission for us to even consider prioritizing an epic that has been on our roadmap since the beginning of time isn't part of our process. To say that it's "pretty obvious that we want to benefit from Mods until they absorb them" is just asinine. Of course we want to benefit from mods. That's why we built an open ecosystem in the first place. And of course a large reason that modules exist are to fill holes in the software in cases where the core doesn't do something yet. To try and re-frame and portray this as a sort of underhanded ploy on our part is just laughable.

Gaëtan Perrault

This isn't trolling. It's really just a really simple business question: If it's important to get done, why don't you just pay WASP / Monk / etc to do it? Why vote? Just put money on your community's plates. You get the feature you want. We, the existing DMs get the feature we want with compatibility that respects our time. It's a win/win.

foundryvtt

I don't know why I'm dignifying this with further response, but I suppose you have successfully baited me. Implementing a feature in core is meaningfully different than copying and pasting the module code. We can, over the course of a development cycle, implement a major feature like this in the core software at the cost of around 6 months of developer effort using the resources we have on the team who are already hired, onboarded, up to speed on our processes, workflows, conventions, and more. Alternatively we could - as you suggest - engage with an external developer on a temporary contract to implement a feature on our behalf. What would that look like? Presuming the developer is willing and able to drop everything they are doing and begin work immediately (probably not) hiring and onboarding means 1-2 months of limited productivity. After that you spend the same 6 months of dev time implementing the module into core (if not longer), plus another ~3 months of dev time from another dev or devs who are responsible for mentoring, reviewing, and learning the code. Overall we end up spending about 10 months of dev time to get the feature added. Then, once the contract is over, the developer leaves the team and we are left with a feature that the remaining members of the team don't fully understand that we then have to continue building and maintaining. What you are (incredibly) saying with a presumed straight face is "why does a company ever develop software in-house when they can just contract out to temporary external developers to do the thing".

Gaëtan Perrault

Right, so let's break this into scenarios. I'll use MATT as an example. Scenario A: You build a partial replacement for MATT in 6 months. PRO: *you* get the feature *you* want. CON: Every GM who currently uses MATT, probably can't upgrade because your replacement isn't compatible (look at what V11 did to MATT). You have a different layer, you have different features. CON: Monk is running around trying to keep V12 up-to-date for his customers while your team changes things. If it's even possible. Otherwise he just gives up. CON: You end up with a feature that you *can* support, but it doesn't do the things that MATT does. So entire support threads are popping up and people are asking why *your* thing doesn't do this other thing. GMs are annoyed because all of their automation is broken. 2 years of those BaileyWiki videos just hang around confusing people. Scenario B: You contract MATT to build a compatible replacement in 12 months. PRO: *you* get the features *you* want and then some PRO: the community gets the features they're already using with better support CON: your team has to spend extra effort and time In both cases *you*, Foundry, get the feature you want. If you do Scenario A, you're doing so at the expense of some existing community members. And I mean that literally. Your community is paying Monk (and others) via Patreon. The humans paying Monk are the same humans paying you. BaileyWiki has hours of videos showing how to use MATT. Lots of people have put real time into this. If you do Scenario B, you get full community buy-in. Module makers get what they want, GMs get what they want. Your existing customers feel respected.

Gaëtan Perrault

> "why does a company ever develop software in-house when they can just contract out to temporary external developers to do the thing" This isn't what I'm saying at all. Because this isn't "in-house" vs "contract out". This is "build vs buy" where "buy" has a contracting component. Twitter bought Tweetdeck, Amazon has tons of acquisitions of companies built on AWS APIs, Microsoft has them for Azure. Big companies do this all of the time, they buy out the successful tools built on their APIs. All of these modules we're talking about are also built on your APIs. Platform companies regularly buy out people who build on their APIs. So what I'm really asking, with a straight face, is why aren't you "buying out" the already successful software that your customers are already using?

Zhell
>>110909874

Stop trying to 'defend the honor' of module makers, dude, we don't want you to. You're being super cringe.

Gaëtan Perrault

I'm not defending "your" honor (Zhell), I'm defending my investment. I'm not just a Foundry Customer. I'm also Customer for several mod developers. I've invested real dollars on these mods. I've invested real hours working these mods in my campaign. Just because they're open source, doesn't mean the mods are free. If a mod is "subsumed" in a way that isn't backwards compatible, I'm out an investment. And so is the community. That's why I'm asking for these popular (and functional) mods to be treated with respect. That's why I'm asking for Foundry to take the extra time and make things as compatible as possible. Because on the other of that mod is the community's money.

Aspen

Sorry if it's already been detailed somewhere, I haven't been able to find clarification on my own, but seeing as Event Triggers and Terrain & Cover are neck-and-neck I thought I'd ask as my vote change could actually matter. Event Triggers as described in the article brings to mind "Monk's Active Triggers" and while obviously I'd like that in Core, it didn't seem as much a priority as Terrain & Cover because there's already a great mod that doesn't break often handling it. Would Event Triggers differ from the mod in function more than I'm picturing or will it be improving, smoothing, and integrating?

bergysb

I voted for Event Triggers. To have a core implementation even 10% as complete as MATT would be a boon for content creators and DMs alike. We need to be able to rely on a stable and robust implementation of this kind of feature set, without having to worry about modules being updated for new versions, or losing support altogether. Just because a core implementation is pushed out, also doesn't mean IronMonk couldn't extend and improve on Foundry event triggers in a way that their current module does for tiles. Having said that, you can vote for as many options as you like, so vote for both if you'd like to have both!

Dumbhuman

Monk's Active Tile Trigger took a bit to be updated to v11. The same author also made the module Enhanced Terrain Layer for marking difficult terrain, but that one's not quite yet updated to v11 nor is Staebchenfisch's module Terrain Ruler which utilizes it. Maybe that will happen soon or maybe they're waiting to see what wins this poll. On the cover side of things, for DnD5e at least there's Simbul's Cover Calculator which is verified for v11. The Levels module I believe gets even fancier with it. I don't think the existence of a module solution should be the deciding factor for this vote. Personally I'm rooting for Event Triggers, because I'd feel a lot better creating fun stuff under a core system than counting on a module to keep up to date with Foundry releases. Also because Terrain and Cover will lay a core foundation, but actual implementation will fall on the system developers since each game has its own rules. So I expect I'd get to enjoy creating Event Triggers a lot sooner than I'd get any functional use from Terrain and Cover.

Anile_000
>>112690815

I see an integrated, native Event Trigger as a solution that actually could be used to build out services. Terrain, in theory, could be field event trigger. (Cover I don't see being able to be driven in the same way) (ie. enter event area and that triggers change in movement costs, until out of area) Placeable items also could be driven by an event. it just seems that a lot of modularity and enhancements could be built from an integrated Event Trigger system that- I agree. I'd see more value in that long term.

revilowaldow

For what it's worth, I'm a strong advocate for tablet (and mobile) support. But I bodge a "disable canvas" button into the login screen. What I want from "tablet support" is support for my players sitting around a table and playing together with a TV, screen or even just paper map in the middle without also having 6 medium power laptops turning the room into a wind tunnel. I want to be able to look at my sheet, or check journals, I want a quick set of buttons to hit to roll. I categorically am not looking for the ability to view scenes on the tablet. Other services provide things like this: https://pages.roll20.net/companionapp Trying to do proper scene support in mobile safari is a path to madness. I really just want to see the sheet which is definitely within the capability of a junk tablet from 2015. Tablet support is about hybrid play, not about tablets as primary devices.

Dawnwolf

I spend on the Foundry Patreon and mod makers' Patreons. it's not an investment. My stocks. bonds and crypto shitcoins are investments. It's money paid to get a good or service, and also to support the creators. While I pay, I get whatever the module does for my game and players. It's immediate value. Not future value. It's worth the money I am paying right that month, and when it's in core, I can decide to stop paying. Chances are there are other modules by the same creator that still are worth the subscription, though. When it's in core, that's one less module and module interaction I have to track. I view that as a good thing. I'd rather have things in core than run 150 modules. That Foundry is API-first is amazing. I remember how that was at the other, web-interfacey place - very few things the API could do, and API plugins were notoriously broken. Foundry is amazing in comparison.

Webby

Not only does it mean we don't have to wait on an update whenever a new Foundry version drops, it also means that official modules can make use of it (i.e. the Pathfinder adventures)

patreon@coffiarts.com

I can't seem to find that reply to the mentioned "first comment", so I am posting here: I warmly second Andy Donndelinger's request: Tablet support ist IMHO one of the key features missing, especially for in-person gaming. I have been using Foundry for in-person gaming for approx. two years now, with the players (of child-age) sitting around a table, and the game world being visualized on shared TV - As it has been excellently summarized here: https://www.foundryvtt-hub.com/guide/using-foundry-for-in-person-gaming/. However, that article is centered around user-made modules like "Simple Mobile" and "Mobile Improvements", which seem to have been abandoned since V9. I'd absolutely LOVE to see Foundry VTT step in itself and close this gap officially. Especially one missing thing for me is an easy-to-use, robust tablet representation of character sheets, replacing the need to maintain paper sheets and keeping them in sync with the digital game. I envision an Android app that can connect players to the game, simply showing the character sheet, including the possibility to trigger dice rolls. And that thing should hopefully NOT be dnd5 only, but be system-agnostic. Such a thing would really make my day, and I continue hoping for it.

patreon@coffiarts.com

I am happy to read that this seems to be baked into the roadmap already! I can well understand that this requires more than implementing a plain "feature", sounds rather like a deep reengineering (naturally taking more than one cycle).

patreon@coffiarts.com

That's EXACTLY what I am hoping for, too! A lightweight app for hybrid in-person gaming, where handheld devices are used for displaying character sheets (replacing pen & paper sheets), and for (optionally) triggering dice rolls (nothing more than that, as scene display will be shared on TV or paper). In my opinion, that would be a big boost!

Angelo Pantano

can we please improve vision API developer experience in v12? The v11 vision is simply impossible to maintain and popular mods like Perfect Vision are dead because of this.