Reply to thread

Message

<blockquote data-quote="Kinematics" data-source="post: 9640242" data-attributes="member: 6932123">Not strictly correct. Invisible doesn't prevent you from being &quot;found&quot; with vision; it only means that you cannot be seen. If I stand behind you, I'm invisible to you, but if you turn around you can see (find) me.Standing behind you makes me &quot;hidden&quot; (non-glossary condition), and being hidden makes me Invisible (keyword). I cannot be seen while hidden because you aren't looking that way/don't know where to look, but that's not the same as not being able to be seen, period.I do like the change they made in the errata. You don't use the Hide action to become Invisible. You use the Hide action to become hidden, and being hidden implicitly gives you the benefits of being Invisible (because that's part of what being hidden means).However &quot;hidden&quot; is not a keyword. There is no game mechanic tied to that state; it's purely narrative. Being Invisible is a keyword, and there are certain mechanical benefits gained by having that condition.They also changed the last paragraph so that it no longer reads &quot;The condition ends on you&quot;, as that seemed to refer to being Invisible, since that was the only defined condition mentioned in the previous paragraphs. The intent apparently was that the &quot;condition&quot; being referred to was the &quot;hidden&quot; condition, but since that's not an actual mechanical condition, it was not obvious. Now you just stop being hidden, which then dominoes into the Invisible condition.They should have added a Hidden (keyword) condition, even if its entire description was, &quot;While you are Hidden, you have the Invisible condition.&quot;&nbsp; There's a certain DRY (don't repeat yourself) approach to the chosen design that isn't actually appropriate. In programming, DRY is taken as dogma by many, but it really shouldn't be. There are definitely times to repeat yourself, and times when an otherwise useless interface layer is appropriate.</blockquote>

[QUOTE="Kinematics, post: 9640242, member: 6932123"] Not strictly correct. Invisible doesn't prevent you from being "found" with vision; it only means that you cannot be seen. If I stand behind you, I'm invisible to you, but if you turn around you can see (find) me. Standing behind you makes me "hidden" (non-glossary condition), and being hidden makes me Invisible (keyword). I cannot be seen while hidden because you aren't looking that way/don't know where to look, but that's not the same as not being able to be seen, period. I do like the change they made in the errata. You don't use the Hide action to become Invisible. You use the Hide action to become hidden, and being hidden implicitly gives you the benefits of being Invisible (because that's part of what being hidden means). However "hidden" is not a keyword. There is no game mechanic tied to that state; it's purely narrative. Being Invisible [i]is[/i] a keyword, and there are certain mechanical benefits gained by having that condition. They also changed the last paragraph so that it no longer reads "The condition ends on you", as that seemed to refer to being Invisible, since that was the only defined condition mentioned in the previous paragraphs. The intent apparently was that the "condition" being referred to was the "hidden" condition, but since that's not an actual mechanical condition, it was not obvious. Now you just stop being hidden, which then dominoes into the Invisible condition. They should have added a Hidden (keyword) condition, even if its entire description was, "While you are Hidden, you have the Invisible condition." There's a certain DRY (don't repeat yourself) approach to the chosen design that isn't actually appropriate. In programming, DRY is taken as dogma by many, but it really shouldn't be. There are definitely times to repeat yourself, and times when an otherwise useless interface layer is appropriate. [/QUOTE]

Verification