Forgot your password?

Comment: Re:5e: Best D&D, MHO (Score 4, Interesting) 198

by seebs (#47709565) Attached to: Fifth Edition Dungeons and Dragons Player's Handbook Released

Doesn't matter how many advantage/disadvantage you have. If you have both, you have neither. If you have only one of those two, then you roll two dice, no matter how many things are giving you advantage or disadvantage.

There are still numeric bonuses, but a lot fewer of them. I think the ones that survive all stack.

But for an example, monks and mage armor. In 3e, the monk got to add their wisdom modifier to AC when unarmored, and mage armor gave a +4 armor bonus, so they stacked. In 5e, mage armor sets your armor class when unarmored to 13+dex, and being a monk sets it to 10+wis+dex, and you can take whichever one you want, but neither is "a bonus" so there's no stacking to resolve.

In general, the net effect is slightly "shallower", but the flip side of that is that you don't have parties where one player has +42 on a check and another player has +3. So you can set DCs that are actually meaningful and interesting.

In epic-level Pathfinder, it takes our party samurai 5 minutes or so to finish a round of full attacks, which can do ~1350 damage. Also lots of die rolls. In 5e, so far as I can tell, nothing takes close to that long.

Comment: 5e: Best D&D, MHO (Score 5, Insightful) 198

by seebs (#47709299) Attached to: Fifth Edition Dungeons and Dragons Player's Handbook Released

I have basically liked all the D&Ds, so I'm a little biased. I even liked 4e, although I recognize that it was a very different kind of game in a lot of ways from the others.

But basically, if you liked D&D pre-4e, and hated 4e, 5e may be what you were looking for. It's a much cleaner system than 3e/3.5e/PF; simpler and clearer. It's not as complicated in some ways. It doesn't have nearly as much detail in the rules, it doesn't have as many formal definitions. But it's clearer and easier to read. And before you dismiss "easier to read" as unimportant, consider: I spent about 10 years on an ISO language standards committee. I assure you, I'm not afraid of formal language. But I like 5e's system better.

Most of the bonus stacking rules are gone, replaced by a mechanic called "advantage/disadvantage". If you have advantage or disadvantage on a roll, you roll 2d20 and take the higher or lower respectively. If you have neither or both, you roll normally. Most things that used to be +2-+4 bonuses of various types are now "advantage", and most things that used to be penalties are now "disadvantage". In practice, you get similar results with a lot less addition, and without having to check the bonus types of 8 different modifiers to figure out which ones stack.

Everyone I know who's played it has been really happy with it so far. The system is much less focused on trying to resolve every possible question; instead, the assumption is that the DM is not an idiot and is not playing maliciously. If you tend towards adversarial player/DM relationships, avoid 5e; it's not designed for that, and it would be horrible. But if you are playing with people who are basically clear on the idea that games are meant to be fun, and who can cooperate without epic rules battles, this is probably the best D&D ever.

The anon coward's "MMO Crap" comment is well past "baseless" into "completely incoherent". 4e had a few traits that sort of, if you squinted just right, looked like it was MMO-oriented, but mostly it was more like wargames than like any MMO I've ever seen. 5e is pretty much like a cross between 3e and Rules Cyclopedia D&D, with a much cleaner and simpler rules set, and a lot more interesting flavor to things.

Other things:

Lots of the "missing" complexity is rumored to be in the DMG as optional rules.

Casters as a whole are significantly nerfed compared to 3e, or for that matter compared to any previous edition. (Max-level caster? You get a ninth level spell per day. Use it carefully.)

There's some really crazy Internet drama about some of the consultants, which is best ignored, and has no basis in reality.

Comment: Re:[citation needed] (Score 1) 200

by seebs (#47697465) Attached to: Involuntary Eye Movement May Provide Definitive Diagnosis of ADHD

There is, but it doesn't change anything, because you're still providing absolutely no evidence to support the claim. And it's still a good example of blaming people being "lazy" for a thing without any evidence. Just-world fallacy; insisting that all the problems are caused by people behaving badly, who therefore somehow deserve it.

Comment: Re: Technical People (Score 1) 194

by david.emery (#47685857) Attached to: The Billion-Dollar Website

I don't know if anyone associated with this project adopted anything they called "agile" or not. What I was saying was that I have zero confidence in "agile" as I've seen it either defined or applied, for products that are (a) large, (b) complex and/or (c) have substantial infrastructure (versus user-facing) functionality. This project had at least (a) large, and probably (c) substantial infrastructure requirements (that might have been solvable by judicious selection of the right commercial products.)

It should be a feature that a waterfall project could be seen to fail early, but for the PM whose career is built on continuing the project past his tenure, there's no advantage to her/him to fail quickly.

Comment: [citation needed] (Score 3, Interesting) 200

by seebs (#47680373) Attached to: Involuntary Eye Movement May Provide Definitive Diagnosis of ADHD

I'd be interested in the basis for the claim about misdiagnosis being "common". I have known a number of people with ADHD who were misdiagnosed with something else. I don't think I've ever met anyone who got a misdiagnosis of not having ADHD.

The quality of the anti-ADHD-diagnosis rants can be pretty much summed up by the fact that people are claiming that a stimulant drug which makes people twitchy is going to "drug people into zombified submission". It really is that blatantly stupid; there is nothing remotely like "zombified submission" on the table.

Comment: Re:F-35 Joint Strike Fighter (Score 1) 194

by david.emery (#47678285) Attached to: The Billion-Dollar Website

...Witness the F-35 Joint Strike Fighter, an aircraft nobody needs, trying to fill too many roles, and was supposed to save our armed services money by having one plane replace many planes...

I'm not defending the F-35 (I'm a huge A-10 fan, and 2 F-35s would fund the whole A-10 fleet), but your comment here is self-contradictory. Either we don't need it, OR it's trying to fill too many missions (that do need to be done.)

I think it's the latter, and that's not just requirements creep, but a different phenomenon that is something like "requirements conbinatorics", where too many requirements get loaded onto a system (health care or weapon) and the result is either (a) not buildable as a violation of math or physics or (b) massively complex and therefore massively expensive.

It's a combination of no discipline on the part of the users/managers who develop the specifications or needs statement, and the problem that the number of major system starts (whether DoD or commercial) is limited, so each user/stakeholder needs to get -His/Her Requirement- in place on this system, because they won't have a chance for another 10 years to get that requirement into their/their user's hands.


Comment: Re:Technical People (Score 5, Insightful) 194

by david.emery (#47676953) Attached to: The Billion-Dollar Website

PLEASE Mod Parent up! I've been working on large government funded systems (defense and commercial) for 35+ years, and in my view programs are screwed from the beginning by overly-aggressive schedules for the up-front work. When the incomplete/absent requirements/architecture/design results in coding, or more often test and integration delays, they'll find more money and time. By then, it's too late.

Back when we had explicit waterfall milestones (requirements review, preliminary design review, etc), we could tell at PDR a program would fail as a result of incomplete or even incorrect requirements & architecture.

Unfortunately, the adoption of "Agile" in these organizations has reinforced the culture of "We don't need no stinking requirements! We can draw an architecture on a whiteboard in an afternoon", resulting in systems where you really can't say anything intelligent about how long it will take to complete them, because you have no fscking idea what "complete" actually is.

And this -should not be a revelation-, at least to anyone who has read "Mythical Man-Month," which will be 40 years old next year.

Thank God I'm getting ready to retire.

Comment: Re:User docs, or developer/maintainer docs? (Score 1) 199

by david.emery (#47672825) Attached to: Ask Slashdot: Should You Invest In Documentation, Or UX?

How often do you need to do that? As an "end user" when things work correctly, I'd assert it's infrequently.

But when trying to debug a problem, I agree this is frustrating, and the worst of all is "You are unable to log in at this time. A system error has occurred." and even if you know how to bring up the Console (/Applications/Utilities/ to look at the error logs, they're not particularly helpful.

So I'll put some words into your mouth and say, "It's important to have documentation available to support troubleshooting or 'power users', but the goal should be that 95% of the time you shouldn't need to RTFM to use the system." Agree?

And access to documentation is separable from existence of documentation. Most of the time, when I'm connected, using a search engine to find this kind of information doesn't bother me. But when disconnected (e.g. sitting on an airplane), not having the information local can be very frustrating.

Comment: User docs, or developer/maintainer docs? (Score 1) 199

by david.emery (#47672259) Attached to: Ask Slashdot: Should You Invest In Documentation, Or UX?

From a user doc perspective, Apple Mac OS X is a great example of what you can do with a minimum of user documentation, but with very mature and fully enforced user interface guidelines. In fairness, someone new to the platform does need some hand-holding, either training (including over-the-shoulder help from a family member :-) or a good book (I'm partial to the Pogue "Missing Manual" series.)

From a developer doc perspective, if you expect to maintain the software, some amount of documentation, that should capture (1) interfaces; (2) design intent; (3) full build/reconstruction directions (including configuration data, etc) is essential. And "Agile" that ignores these documentation/sustainment issues is just an excuse for write-only coding.

Science is to computer science as hydrodynamics is to plumbing.