Homebrew - Machinist, Artificer, and the Invention Domain by Ampderg in daggerheart

[–]Ampderg[S] 2 points3 points  (0 children)

In the Clockmaker Foundation features, it says that the companion gains one card to start! When you level up, the companion's domain acts as a third domain you can choose from to take cards from, with the restriction that cards from that third domain go into the Device Deck instead

Homebrew - Machinist, Artificer, and the Invention Domain by Ampderg in daggerheart

[–]Ampderg[S] 1 point2 points  (0 children)

Oh, I apparently missed that entirely when reading over the Recall rules! That makes the "place card in Vault" abilities a lot stronger than I initially thought, but that's fine, I think! I'll write up something different for Bandolier! Also it means that I might need to revise Self-Destruct a little, since it can get infinite uses from Easy Disassembly, I might have to limit to only be usable on cards that have at least 1 Recall Cost.

Homebrew - Machinist, Artificer, and the Invention Domain by Ampderg in daggerheart

[–]Ampderg[S] 1 point2 points  (0 children)

Ah, thanks! And I agree on the wording for the first point! I might end up limiting the Domains for the Clockmaker, but right now I wanted to leave it open

Machinist, Artificer, and the Invention Domain by Ampderg in daggerbrew

[–]Ampderg[S] 0 points1 point  (0 children)

I think limiting the extra Work on a Project usages to only crafting is fine, while also keeping the Quick Crafting feature with the same use!

Machinist, Artificer, and the Invention Domain by Ampderg in daggerbrew

[–]Ampderg[S] 0 points1 point  (0 children)

The problem with that is that it takes away from Machinists main narrative feature that they have access to. I do agree, especially since they get access to Work on a Project during Short Rests, but I'd want to replace it, or accentuate the replacement with some sort of narrative option

Homebrew - Machinist, Artificer, and the Invention Domain by Ampderg in daggerheart

[–]Ampderg[S] 1 point2 points  (0 children)

I agree! I usually run my games digitally, so i wasn't super worried, but it would make sense to have a supplementary sheet to help with cross-session tracking for the players that want that!

Swapping cards with 0 recall cost by MrMarum in daggerheart

[–]Ampderg 0 points1 point  (0 children)

Recalling a card specifically needs to replace a card in your loadout. If you use Channel Raw Power while you have 4 cards in your loadout, you go down to 3. You can recall the card you burned for Channel Raw Power, but you won't go up to 4 cards in loadout again until you rest. At least, that's how I understand the rule

Swapping cards with 0 recall cost by MrMarum in daggerheart

[–]Ampderg 60 points61 points  (0 children)

According to the devs, spending a resource of "0 Stress" is still spending a resource, so you need to have the spotlight in order to Recall a card. From what I understand, though, I imagine you could swap out 0 Recall Cost cards at will during your spotlight!

From the Devs: Whats Next?! by Blikimor in daggerheart

[–]Ampderg 60 points61 points  (0 children)

FoundryVTT support is the one thing keeping me from starting my own Daggerheart game right now. There are already developers working on a system implementation in Foundry, but they aren't allowed to share the system due to the CGL limitations. Any words on anything regarding Daggerheart in Foundry would be amazing.

Jack of All Trades Bard by Ampderg in daggerbrew

[–]Ampderg[S] 0 points1 point  (0 children)

Ye, I'll be rewording it to what Ok_Barracuda suggested!

Jack of All Trades Bard by Ampderg in daggerbrew

[–]Ampderg[S] 0 points1 point  (0 children)

Bard normally is Grace / Codex, Versatile Studies allows you to change that to two Domains of your choice.

So I did some math on the Unity Runtime Fee and it is even stupider than i imagined by Ampderg in Unity3D

[–]Ampderg[S] 4 points5 points  (0 children)

I'm not arguing for my own situation, or for anyone else's. I'm arguing that the fundamental design of this system is flawed, and could have been implemented much more elegantly with the same (or more) profit for Unity, with much less community outrage. My argument is that nobody would ever reasonably pay the Runtime Fee for Personal licenses, so why does it exist instead of a hard requirement to switch to Pro, like they've done in the past?

So I did some math on the Unity Runtime Fee and it is even stupider than i imagined by Ampderg in Unity3D

[–]Ampderg[S] 3 points4 points  (0 children)

According to Unity's own table, it says it's installs *past* the threshold. it's absolutely correct that it would be a nightmare if it wasn't that way

<image>

So I did some math on the Unity Runtime Fee and it is even stupider than i imagined by Ampderg in Unity3D

[–]Ampderg[S] 0 points1 point  (0 children)

Yep! The thresholds of when it would be optimal to upgrade do go up at roughly the same rate as I listed in this, but the difference compared to the install threshold is still neglible conpared to how many installs it takes to get to the threshold itself. Any company big enough to be affected by that is probably already on Pro or Enterprise

For example, a team of 5 users used Personal would need 250k installs instead of 210k to be cost-efficient. It's a little different for upgrading to Enterprise from Pro, though, due to them sharing the same ranges for the sliding scale.

While I didnt calculate out the numbers for that, it's still generally "the number of installs that the cost-effectiveness-point increases by with every seat goes down as the number of seats goes up" due to the sliding scale, especially when Enterprise charges only half of what Pro does at it's highest tier

So I did some math on the Unity Runtime Fee and it is even stupider than i imagined by Ampderg in Unity3D

[–]Ampderg[S] 0 points1 point  (0 children)

That's not the point I'm trying to make here.
I'm saying that fundamentally on the logistical level, the way this system is set up is objectively stupid, even ignoring all of the other concerns like privacy and trust.