Thanks for taking the time to post a new comment or a reply to one! First scan these quick notes, if you please:
General
* Currently, previewing a post is optional; you're welcome to preview or post immediately.
* You should see plain text input by default; click "enable rich text" for fancy formatting tools. (Some people love that and some don't. Be aware that formatting tool performance may vary by browser.)
* With apologies to all, I have to use a simple "captcha" question for unregistered posters. Otherwise, the spam flow will dwarf the Nile.
Registration and login
* Registration is available! Sign up here. Chief benefits at present include the ability to edit your own comments and manage subscriptions (newsletter, threads, etc.).
* If you'd prefer to post as an unregistered visitor, that's welcome too. Just leave "Your name" as the default "Esteemed Visitor", or type in some other name. (But if you happen to type in a name used by a registered user – say, "tbone" – you'll get an error telling you so when you hit "post comment". And while your post text should still be there, waiting for a revised user name, there's a chance it could disappear.)
* If you're a registered user but haven't logged in and want to post a quick comment as Esteemed Visitor, that's fine; see above.
* If you're a registered user but haven't logged in, and enter your user name under "Your name" when posting, you'll get an error saying that's the name of a registered user. That's a good thing; it means strangers can't make posts under your user name! But as above, there's a chance of losing your post text. It's best to log in first here, and then start your posting.
Final
All the above is standard stuff for community web sites, but reminders are good; I hate post-related glitches, and hate to see people run into them on this site. On this or any site, it's a good practice to do a quick "Select All" and "Copy" on your post text before hitting "Preview comment" or "Post comment" – just in case.
For more on the whole topic of interaction with the site, please see User Interaction (opens in new window).
Is this your first visit? Consider subscribing to this site's RSS feed to get updates, or to the newsletter for the occasional mailbox surprise.
(Were you, by chance, searching for "diner games"?)
This site is full of original material for players of table-top role-playing games. Input and collaboration is welcomed! Please read more about the site here. Or just dive in to whatever looks interesting.
A couple of recommendations: GURPS players, check out what's at The GURPS Diner. The house special is GULLIVER, an easy rules expansion for creating and playing odd-sized creatures. To see the lunch, dinner, wine, and kids' menus all at once, peek at the site map. Take your time; the busboy will be along shortly to clear you a place.
This site – like wide swaths of the Web – may not display properly with Internet Explorer 6.0 or lower. For your own sake, please upgrade to 7.0 or higher! Or even better, to fully enjoy the Web, try Safari or Firefox.


Misreading DECIDE?
Discussion of DECIDE still goes on at http://forums.sjgames.com/showthread.php?p=455454 .
Here or in SJG forum threads, most comments are very favorable, but the article receives some "objections" as well. I place the word in quotes for a reason. Some "objections" are mostly agreement ("Yeah, it makes lots of sense in this situation, and generally for these characters in this situation, and maybe here as well..."). Some are flat-out wrong (see any comments about extra rolls, extra bookkeeping, extra complexity, "wargaming", etc.). And some... well, there are persistent "objections" whose target I can't figure out.
From more recent comments, I think I see what a few readers may be misunderstanding.
Recap
DECIDE looks at two situations:
Difference from RAW
A is RAW: no defense commitment until you know TH. As far as I know, nobody has any complaint with that. We can all agree that A can be a perfectly realistic situation.
The RAW oddity is this: RAW allows only A – for all fighters (from Conan to my grandmother), in all situations, versus all threats – even invisible bullets. RAW has no provision for B.
DECIDE suggests allowing B as well. And when bullets fly, almost everyone who's commented agrees that B makes more sense. It's only the case of melee that generates debate, which leads us to:
The (possible) misinterpretation
As best as I can guess, objections along the line of "a skilled fighter shouldn't waste defense on an attack that will miss" or "a skilled batter can see where a pitch is going" are misinterpreting DECIDE as tossing out A.
If that's what anyone is reading, let me correct it. DECIDE keeps A. DECIDE likes A. It only suggests that we disallow A where it'd be unreasonable – namely, in the case of bullets.
DECIDE even likes A in melee! A should certainly exist in melee – but so should B. Otherwise, we're claiming that low-skill fighters and librarians will always, unfailingly, identify every blow that'll miss by an inch, with 100% knowledge that there's no need to commit to defense. And that's not realistic.
(See article text for consequences of allowing B in melee – and add the point that without it, you can't even game real situations like a hapless batter swinging at an outside pitch.)
Summary
RAW allows only A.
DECIDE allows both A and B, whichever is appropriate for the situation.
A possible source of misunderstanding is thinking that DECIDE tosses out A and allows only B, which isn't so.
If that clears up any misunderstanding, good!
Final note
As with any area of rules, there are two levels to the thing: the idea and the implementation.
The idea to allow B in combat is a good one, and an argument of "B is never realistic" cannot win.
That said, how I chose to implement the idea – the mechanical difference between A vs B; when A and B each are and aren't possible; which fighters perform A and which perform B; etc. – is just one possible implementation, and of course can be argued, tweaked, and even improved upon.
The point being: If any reader still sees some problem, I welcome your words – but please make clear whether it's an objection to the idea of allowing A and B as above, or to the suggested implementation. (I gotta add: There's plenty of room to dislike the implementation, but arguing against the idea is one tough sell!)
And with that, there's nothing to add except for the standard disclaimers: It's all optional for the interested only; it's really trivial stuff in terms of effect on game play; blah blah (you know the drill).