[Tome] AwesomeTome v2 clarification

[AndreiChekov]

I can proof read for grammar.

[TarkisFlux]

No, we're not doing word docs. Word docs are not a valid submission format. Word docs are horrible. You can use plaintext or you can use bbcode (form-post formatted text) or you can use latex. Those are your options. Those are your only options.

You can at least write your stuff as a form post, we'll take it from there if that's all you want to do. But we are not using .doc files.

.doc files can fuck all the way off.

Word (irony intended).

I'll be PMing people who have expressed interest in contributing to see if they're willing to go in with me in some sort of lead position, and to make sure they see this. Because if they're not willing to work with me in this position, there's no point.

And I'll be responding to that here. I've got that PM from you, and I've got an email and/or PM or two from CodeGlaze, and it's getting weird because there's also two or three threads on this subject floating around the main board.

We need to pick a thread, either an existing one or a new one, and then I think that ALL communications about the matter should go in just one thread. Unless an actual file is being sent or something, stick to just using the thread.

Responding here is good because silence on this is frustrating and makes it look dead, again. Organizing contributors needs to happen in one place and be as transparent as possible (and it might as well be here), and then they need to be pointed to the repository for more specific issue discussion. Broad polls and discussion can happen here so we're not completely cut off from a potential target audience, but general discussion here is counter productive to getting things actually done.

Options 2, 3, or 4 seem workable. Option 1 is dumb. There's no reason to start over and just get the same result. The AwesomeTome is already a compilation. We need to merge the Tome material, however much of it, with an SRD base so that a complete game is the result.

In terms of specific mechanical changes to implement or not, I care very little. I think that 3 is possibly better than 2 on account of the fact that we at least have to complete the magic item stuff, so we'll already be writing a bit, so we might as well fix at least a few of the major gripes. 3 is probably more realistic than 4.

At the same time, too many small changes just for changing sake ends up with one of the pathfinder problems, where you can't remember what changed and what doesn't. So maybe some things we want to just leave alone if there's not going to be an obvious difference with the change.

I'm going to assume this means you're okay with me as supreme overlord organizing producer or whatever. Sigil and codeGlaze have responded similarly in PMs.

I agree with your assessments of those levels. 1 is basically in there as an errata update for people who are happy with existing document, so it's not completely pointless and will probably happen anyway. We need to update classes, and at that point we can just fork it all out and compile and call it done.

Your caution about including too much for its own sake is well taken though.

@Lokathor : Tarkis and I talked about it. We're going to set us up the bomb. I just need to get home first.

It's partially my fault for the poor communication until recently.

Poor communication is the death of volunteer projects. People drop out and come back or join late and don't know what's going on, and then don't do anything at all. Under my iron fist in a titanium glove organizationing, communications will happen with more regularity. Probably.

Placeholders for directions and getting started pages and task lists will be present anyway. My wiki and issue access on the main repo came through, so I will be populating them with how-tos and style guides and things shortly so stagnation is less of a problem while we sort low level things.

Which reminds me, you didn't specify am acceptable or preferred output format codeGlaze. Specify some combination of 1-4 please, if only to frame future discussions.

I can proof read for grammar.

Did you want to proofread any of those outcomes for grammar and whatnot, or were there some so uninteresting that you'd pass?

[Lokathor]

In the past I've done rather well I think when taking what others have given me (Frank's two big projects, or the SRD) and then formatting that into a PDF, so I'm fine with others selecting what's in and out on this project as well. I suppose I'd like to be the ultimate editor of the LaTeX itself, but there's honestly just too much of it for one person to handle it all in a reasonable way. I expect I'll end up setting up the outline and common functions that will be used while everyone else fills in and works on individual sections. Unless someone else is highly experienced with LaTeX and hasn't mentioned it until now.

In terms of proofreading people, everyone should be doing some of that hopefully. Ideally we would be posting submissions and updates on a regular basis, so that as each new thing comes in people can look at it closely, and we can iron out bugs. Then again, even now I still catch the occasional punctuation mark out of place in my PDF of After Sundown when I reread some sections. Such is the benefit of an electronic format, we never have to stick to a "final printing" version.

[Bihlbo]

No, we're not doing word docs. Word docs are not a valid submission format. Word docs are horrible. You can use plaintext or you can use bbcode (form-post formatted text) or you can use latex. Those are your options. Those are your only options.

You can at least write your stuff as a form post, we'll take it from there if that's all you want to do. But we are not using .doc files.

I wasn't asking for .doc files because I wanted to contribute, because at the time this whole thing looked like it would get about as far as the "new edition" project that was abandoned before it got anywhere. I didn't intend to submit anything - my need for the files comes from wanting to run a Tome game with a more complete document, put in my own revisions, and finish it for my own uses. A pdf doesn't get me there, and for a project that will only be seen by me and 5 players, I don't give a fig if some other format is better than the format that is easiest to use.

Now that the project at least has someone willing to lead it, I'm much more optimistic about it and eager to work on it in the format required, but that doesn't mean my need for a simple, easy to use version of the pdf for my own game has gone away. I still want that converted to .doc. Edit: This is not to say I'd rather work on my own game than this project, but my game is probably going to get started within 6 months and there's no way to tell when this project will provide me with a working SRD-level product to use before then. Having the option would be nice.

[Bihlbo]

I volunteer to wear that hat and run this thing organize this thing as outlined above. I'll be PMing people who have expressed interest in contributing to see if they're willing to go in with me in some sort of lead position, and to make sure they see this. Because if they're not willing to work with me in this position, there's no point.

I'm behind you 100%, TarkisFlux, and thanks for doing the work!

First off, as I think about the work being done I can foresee a time when there will be a dozen or more different discussions going on at the same time. It would probably be worth a separate sub-board, if fbmf wants to do that. Otherwise, at the least we'd need another sticky for the new-new edition list of threads. A sub-board seems simpler and cleaner to me.

I would like to volunteer to be assigned work, TF. Aside from commenting on work others are doing, I'm probably going to be a lot more involved once a list of tasks is available. That said, I'm pretty good at content editing (meaning I can turn a quick but working class into something that looks like it came from the PHB) but I have no experience with latex.

I foresee three main issues being a rather huge chunk of the work needing to be done:

• Classes - Start with those F&K did, apply what fixes are needed, then all the community-produced classes turn this part of the project into something rather huge; specifically which ones are in, why, how to standardize, etc.
• Setting - Maybe this doesn't need revision but some of the best work I've seen done for the "new edition" was in setting, and it's an important part of the game so maybe this is something we want to tackle.
• Magic items - Balance is a big issue here, and the sheer number of possibilities makes this almost as enormous as revising the entire spells list. We should aim for having something a person would prefer to use when the Magic Item Compendium is also within reach (not for the quality of the magic items or how powerful they are, but for how easy that book is to use as a player or GM).

I'm not an ideas guy, I'm an analyst and editor. I'm gonna be poking holes in things and suggesting changes, but I'm probably not going to write a new class or come up with totally new setting elements or things like that.

[Lokathor]

No, one thread. I'm totally serious. If we hit the post cap for a thread we can start a second one, but otherwise we can just stick to one single thread.

The actual number of people that will be touching the document code itself will be small, less than 10 people, possibly less than 5 people. Those people will have to read through the thread and keep up to date on all things.

Everyone else can just skim past posts that are about a chapter they're not working on or whatever, but it's better that they're at least aware that things are moving along. Since the forum's "you have unread posts" feature is totally broken, it's easier to not split things so that people can just keep track of how up to date they are in a single discussion thread.

LaTeX is not actually hard. It's basically like HTML or any other markup language, but you can also add your own commands as part of a document (which we'll be doing to make things simpler for the writers).

The SRD Monk class features section literally just looks like:

Code: Select all

\textbf{Bonus Feat:} At 1st level, a monk may select either \linkfeat{Improved Grapple} or 
\linkfeat{Stunning Fist} as a bonus feat. At 2nd level, she may select either \linkfeat{Combat Reflexes} 
or \linkfeat{Deflect Arrows} as a bonus feat. At 6th level, she may select either \linkfeat{Improved Disarm}
or \linkfeat{Improved Trip} as a bonus feat. A monk need not have any of the prerequisites 
normally required for these feats to select them.

\textbf{Evasion (Ex):} At 2nd level or higher if a monk makes a successful Reflex 
saving throw against an attack that normally deals half damage on a successful 
save, she instead takes no damage. Evasion can be used only if a monk is wearing 
light armor or no armor. A helpless monk does not gain the benefit of evasion.

\textbf{Fast Movement (Ex):} At 3rd level, a monk gains an enhancement bonus to 
her speed, as shown on Table: The Monk. A monk in armor or carrying a medium or 
heavy load loses this extra speed.

\textbf{Still Mind (Ex):} A monk of 3rd level or higher gains a +2 bonus on saving 
throws against spells and effects from the school of enchantment.

Totally comprehensible if you're just doing the low level organization stuff.

[TarkisFlux]

In the past I've done rather well I think when taking what others have given me (Frank's two big projects, or the SRD) and then formatting that into a PDF, so I'm fine with others selecting what's in and out on this project as well. I suppose I'd like to be the ultimate editor of the LaTeX itself, but there's honestly just too much of it for one person to handle it all in a reasonable way. I expect I'll end up setting up the outline and common functions that will be used while everyone else fills in and works on individual sections. Unless someone else is highly experienced with LaTeX and hasn't mentioned it until now.

Not a LaTex guru (though I'm probably going to enjoy learning more of it, because nerd and MS swears by it), but I figured I'd sort general organization and content selection/incompatibility/merger issues and leave the technical details of getting it all in there to you (and then learn how you did that stuff). I expect to mostly organize progress, direct other contributors, fill in needed stuff, and be the decider end otherwise endless discussions so that the project isn't languishing. But if that sounds like too many cooks and you've got time to sort contributors, I'm happy to back down / out.

[TarkisFlux]

First off, as I think about the work being done I can foresee a time when there will be a dozen or more different discussions going on at the same time. It would probably be worth a separate sub-board, if fbmf wants to do that. Otherwise, at the least we'd need another sticky for the new-new edition list of threads. A sub-board seems simpler and cleaner to me.

No, one thread. I'm totally serious. If we hit the post cap for a thread we can start a second one, but otherwise we can just stick to one single thread.

If I have to choose between these two, I choose the second. It's a shitty option that leads to really bullshit distractions and derailments by people who want other people to make their game for them, but it's better than asking for a whole sub board for a project and having those same people fuck up a dozen threads.

I wasn't kidding when I said elsewhere that serious discussion on this matter shouldn't be on the Den. Catharz is not wrong that it will be derailed and argued into the fucking ground by people with their own pet peeves. For fucks sake, the classes thread asked what classes should be included, and how many straight answers did you get aside from mine? You want to do that for every inclusion decision?

Git supports issue tracking, and we may as well use that for determining the shape of the book, each chapter, and each sub-chapter early on rather than using one large thread here (after determining how far the majority of contributors are willing to go anyway). If you want to keep it palatable here you bring back polls or whatever, but general thread here is just asking for it to be taken back underground into PMs or emails to avoid bullshit. It's better than a bunch of ruined threads, but not by much.

[Lokathor]

Personally, I'd just disregard anyone who kept going on about an issue once the editing team had made a decision. Koumei has final say over Dungeon Crusade, Frank has final say over After Sundown, and the editors would have final say over the "Tome Reference Document" (name pending). If people get so upset that they want to take their ball and go home... go ahead. That's exactly what Git is designed for.

I can see how you might not want to go that route perhaps. I'm always in favor of the most openness possible, but perhaps that's not always best.

I expect to mostly organize progress, direct other contributors, fill in needed stuff, and be the decider end otherwise endless discussions so that the project isn't languishing. But if that sounds like too many cooks and you've got time to sort contributors, I'm happy to back down / out.

No, no, this sounds just right to me. Like I said, others mostly decide what goes in the book, I mostly put it in the book.

[TarkisFlux]

I'm not saying the editing team's decisions should be hidden, and they'd be public on Git anyway. I just want a place where they can discuss things on their own without getting into arguments with non-contributors like they would here (technically, non-contributors who weren't sufficiently passionate to follow a link elsewhere, register, and then post their complaint since you can just do all that shit on Git, but that seems sufficiently invested to matter to me). If those decisions get reported back by someone and then an argument happens, that's all well and good and should probably happen anyway, but asking people to wade through it during the initial process seems entirely counter productive.

[Edit] Also, Git's wiki and issues capabilities provide a cleaner and faster way of looking up current status, style guides, how-tos, and whatever else we care about than a massive run-on thread does. Someone new wants to contribute? Link them to the Git wiki page to let them get up to speed and call it a day. The lower the barrier to actual contributions the better.

[Vebyast]

If we do our jobs right, we'll be using github's issue tracker more than we do any forum thread. Except for a few very, very high-level things, like the very initial "what is the scope of this project?" and "what technologies are we using?" discussions, we should be doing all of our talking in issues. For example, based on how this thread is going already, we probably want an issue for "Fix multiclassing". Issues are better-integrated with the document we're working on (references are possible both to and from the code and from commits), track official state and context better (marking issues as "rough draft" or "wontfix", what everybody is working on, that kind of thing), and are generally cleaner than bouncing back and forth between the forum and the code in an editor. Wikis are also a good place for things that won't go into the final product but are still useful, like a writeup of the our mission statement, math-hammering, and same-game tests of any modifications we make. Forums don't work for those things at all, mostly because you end up being unable to find anything or relate a particular forum post to a particular revision of the document.

I do think that we should occasionally bring milestones and important topics back over to the forum for general discussion. "We have a rough draft of the document with fully-integrated item rules, have a look at this PDF and tell us what you think."

[TarkisFlux]

So that is you over there following the project then Vebyast (convenient globe consistency you have going on)... cool. And yes, that was my super secret totally telegraphed plan (more or less anyway, still learning some of the Git features). There's an issue about which subsystems should be on the table for makeovers there already actually, and if you're planning on committing edits you should go drop in there and put some things up on the block. Multiclassing seems an easy one, but I thought I'd query editors about their pet peeves all in one place before we started in on specifics.

Oh, wait, you're doing that already. Good times.

[Vebyast]

So that is you over there following the project then Vebyast (convenient globe consistency you have going on)... cool.

[...]

Oh, wait, you're doing that already. Good times.

Heh. I'd prefer keeping this handle at least slightly separate (don't want people to be able to put things together without at least two google searches ), but, yup, that's me.

[AndreiChekov]

I am willing to proof read anything. I don't know anything like latex or html, but I can make sure all the words and punctuation are correct and in the right places.

Also, if you are really stuck on fluff/flavor for something, I have experience in writing that sort of stuff. I just need a guideline, like how in the 3.5 PHB they have different sections of fluff for each class; role, religion, best ability scores for the class... etc.

Also, I don't care one bit about what goes in. I will write my own add on for it, that fits my preferences, when it is done.

I am capable of writing about 2 pages each night, and proof reading about 80.

[Lokathor]

For LaTeX basics:
http://en.wikibooks.org/wiki/LaTeX

[Sajber]

The only thing that I have as a complaint is that the part where it talks about combat doesn't use the Frank and K system.

Hmm, I thought I just grabbed everything from the Tomes and that the combat in there was Frank & K's system. What did I miss?

[AndreiChekov]

Hmm, I thought I just grabbed everything from the Tomes and that the combat in there was Frank & K's system. What did I miss?

The edge

[codeGlaze]

Wow... I completely missed an entire week of conversation in this thread... and have no idea how.

The only thing that I have as a complaint is that the part where it talks about combat doesn't use the Frank and K system.

Hmm, I thought I just grabbed everything from the Tomes and that the combat in there was Frank & K's system. What did I miss?

Que?

[Kaelik]

I just read something Koumei posted in the Annoying questions, and I have to bring this up.

AwesomeTome is the shittiest name that has ever shat.

Tomes are fine. Fucking make up your own name if you want. Call it the NewTome, or CompleteTome or MoreTome, but for god sakes don't call your stupid project AwesomeTome, it literally hurts me to know that that name is being used.

[Sajber]

Hmm, I thought I just grabbed everything from the Tomes and that the combat in there was Frank & K's system. What did I miss?

The edge

But the Edge is in there. Lots of times! At least a lot of Edge options for maneouvres and such... I couldn't find any section explaining it though, so that must be why you didn't see it.

[TarkisFlux]

I just read something Koumei posted in the Annoying questions, and I have to bring this up.

AwesomeTome is the shittiest name that has ever shat.

Tomes are fine. Fucking make up your own name if you want. Call it the NewTome, or CompleteTome or MoreTome, but for god sakes don't call your stupid project AwesomeTome, it literally hurts me to know that that name is being used.

It's not being used going forward. Tome Reference Document (TRD) is what I refer to it as when I need to, but we'll find a new name for it before it gets finished.

[AndreiChekov]

Hmm, I thought I just grabbed everything from the Tomes and that the combat in there was Frank & K's system. What did I miss?

The edge

But the Edge is in there. Lots of times! At least a lot of Edge options for maneouvres and such... I couldn't find any section explaining it though, so that must be why you didn't see it.

It's buried somewhere in Races of War, but I don't actually follow that rule myself, so I'm not going to look for it or suggest it.

What I use is that you can only make AOs against creatures that you have the edge against, and if you want to know whether or not you have the edge, just ask the DM cause you can tell that sort of thing.

[Midnight_v]

Its under "Advanced combat"

Edge Mechanics

Base Attack Bonus and Combat Maneuvers

If you looked at the classes in the PHB, you'd think that BAB actually meant something. Classes with good BABs are severely restricted in other areas, and they only get 1 or 2 more BAB every four levels as compared to full spellcasters. Clearly, having even a slight bulge in BAB is supposed to be a major advantage. But in the basic rules, it really isn't. The bonus that a Fighter gets to his BAB over a Wizard is actually smaller than the variance of having rolled well and having rolled poorly on one's attributes. There is no guaranty that an Elven Fighter is better with a bow than an Elven Wizard is at 1st or even 4th level. Even when the BAB starts to pull ahead, it does so very slowly. A net +1 to-hit is something that you seriously might never even notice if you rolled your dice in secret. A +1 to-hit means that out of 20 attacks, one attack that would have missed would hit instead. Which, compared to the difference in numbers of attacks that land between someone who rolls well and someone who rolls poorly during an adventure is vanishingly small.

So what we're doing is actually making BAB mean something. It's supposed to represent the amount of combat skill you have, so let's work with that. From now on, if you have more BAB than the target of your attacks, you are considered to "Have the Edge" on that attack. Combat Maneuvers will perform better when used by someone with the Edge. So while anyone can attempt to Disarm an opponent (provoking an attack of opportunity and dropping the weapon on the ground on a successful opposed attack roll), a character with the Edge can disarm better (provoking no attack of opportunity and sending the weapon flying in a direction of his choice). In this manner, a character who takes full BAB classes always has a fundamental advantage in combat over characters who do other things.

There is more... I linked that from here: http://dnd-wiki.org/wiki/Races_of_War_% ... _Maneuvers