Reply to thread

Message

<blockquote data-quote="ryryguy" data-source="post: 4861108" data-attributes="member: 64945">That's correct... but you need proficiency first before you can take the new feat, which might require another feat, unless you get it from your class.It's definitely more complex, but it's meant as a compromise for those who feel that the feats are too strong to just do away with the multiclass restriction across the board.&nbsp; The compromise allows some to get the full power of the feat with a single feat choice, but doesn't open up them up to be grabbed by anyone and everyone wholesale.&nbsp; It ends up being the same as your proposal for Tonk, but not for all characters.So, yes, more complex, but is it too complex? If you think that adding proficiencies to classes makes it too complex, it could be changed to make membership in that class a requirement for the feat, instead (and go back to granting the proficiency in the feat, too).&nbsp; That seems like mostly semantics, but I guess it does put all the changes in one place - the new feats.&nbsp; And the new feats themselves are not all that complex, they are just the original feats with a different requirement.Here's an alternative compromise.&nbsp; Change &quot;multiclass&quot; to a new keyword &quot;weapon mastery&quot;.&nbsp; A character may only choose a single &quot;weapon mastery&quot; feat.&nbsp; (So basically it works the same way as multiclass, but in a new, separate namespace.)That is much more simple, but it also doesn't restrict the feats quite as much, so it may not fully satisfy those who are worried that the original proposal gives up too much.&nbsp; It does have the happy bonus effect that bards would no longer be default weapon mastery masters!&nbsp; No one seems to like that aspect of the originals.Well, anyway, obviously I'm not a judge, and most of the people discussing this aren't judges.&nbsp; So I'm not even sure if the judges are looking for a compromise, but if they are, there are a couple.&nbsp; <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile&nbsp; &nbsp; :)"&nbsp; data-smilie="1"data-shortname=":)" /></blockquote>

[QUOTE="ryryguy, post: 4861108, member: 64945"] That's correct... but you need proficiency first before you can take the new feat, which might require another feat, unless you get it from your class. It's definitely more complex, but it's meant as a compromise for those who feel that the feats are too strong to just do away with the multiclass restriction across the board. The compromise allows some to get the full power of the feat with a single feat choice, but doesn't open up them up to be grabbed by anyone and everyone wholesale. It ends up being the same as your proposal for Tonk, but not for all characters. So, yes, more complex, but is it too complex? If you think that adding proficiencies to classes makes it too complex, it could be changed to make membership in that class a requirement for the feat, instead (and go back to granting the proficiency in the feat, too). That seems like mostly semantics, but I guess it does put all the changes in one place - the new feats. And the new feats themselves are not all that complex, they are just the original feats with a different requirement. Here's an alternative compromise. Change "multiclass" to a new keyword "weapon mastery". A character may only choose a single "weapon mastery" feat. (So basically it works the same way as multiclass, but in a new, separate namespace.) That is much more simple, but it also doesn't restrict the feats quite as much, so it may not fully satisfy those who are worried that the original proposal gives up too much. It does have the happy bonus effect that bards would no longer be default weapon mastery masters! No one seems to like that aspect of the originals. Well, anyway, obviously I'm not a judge, and most of the people discussing this aren't judges. So I'm not even sure if the judges are looking for a compromise, but if they are, there are a couple. :) [/QUOTE]

Verification