squeeg / awesometome Goto Github PK
View Code? Open in Web Editor NEWA compilation of Gaming Den DnD 3.X changes. Started by Frank and K.
Home Page: http://squeeg.github.io/awesomeTome
A compilation of Gaming Den DnD 3.X changes. Started by Frank and K.
Home Page: http://squeeg.github.io/awesomeTome
So I've noticed that a lot of us are itching for substantial changes as well as a simple Tome compilation.
Substantial changes, or a new edition, require a lot of prep discussion and theorycrafting as we are probably all aware of.
It seems like most of us have a lot of overlap in what we'd like to see in a new edition.
So would it be feasible to discuss plans for a New Edition while we are still focused on putting together the Tome compilation?
It already seems like there is a lot of synergy between the two... so I figured I'd make a discussion out of it.
The following classes are either original Tome classes or filling in SRD spaces, and are core classes for TRD and thus high priority for conversion. They need to be updated to use the new class functions, and incorporated into the main document. We can errata them later (and we will want to for some of them)
The following classes are also core TRD but should not be converted yet, pending discussion or more general edits:
Secondary priorities include the following, likely in the form of addendums / supplements:
If/When we get more contributors we might want to start claiming projects in thread to reduce redundancy, but for now it's probably ok if you just do stuff and commit it.
Hey everyone,
The v0.7 and v0.6 folders are legacy folders. :)
Sorry if that confused you. :(
Hello project contributor! Your willingness to contribute your time gratis entitles you to a say in this, and every other open, issue thread for this project. And this is the most broad of them all.
The issue here is simple enough to start with, but really really thorny in the details. We know that we're going to edit some things together and replace some SRD things. Grappling, for example, is almost certainly going to be F&K bits rather than the normal SRD nonsense. Other things are less clear though. We have a chance to make some changes system wide, and we should sort those changes at the outset so we don't invalidate a bunch of work later on.
So, what do you want to see changed, and what would you like to see it changed to? Here's some examples of things that we could alter:
*Resource Management Systems (like spell slots)
*Multiclassing
*Skills
*Feat Progressions
*Equipment and Magic Items
*Alignment
*Combat
If you have anything you really really want tweaked, say so now and make the case for it. You may not get your way on everything, but hopefully the rest of it is something you can get behind and you can just do minor tweaks at your own table. The aim is for your work to be of benefit to you after all, not just for you to make someone else's game for them. And if the ultimate direction is something you really can't get behind, you always have the option of contributing some things and forking the rest out for yourself.
I've been toying with a spell template that works in a 1-column format, but I'm having problems with getting the spell data set nicely. There's a floating figure in the assassin class that sits on the right and text flows around it on the left, but I can't get a float on the left with text around it on the right. And since I'm not having look on my own and I'm tired, I thought it time to ask for assistance.
So @Lokathor, @ExplosiveRunes, @SqueeG... anyone got anything?
What time zone, and schedule (roughyl), are you all on?
I'm US-EST, most useful/active after 6PM normally.
Book needs a name. Hardest part of anything really. Feel free to just drop ideas in here, whether they be good, bad, or other.
This will likely be open for a long, long time.
TarkisFlux, since you're the project manager I figured I'd pose this question to you. Are there any small items you want formatted for inclusion in the pdf? Classes, rules, etc? It's great that we're hashing out formats and everything, but I'd like to start working on some stuff in the mean time to get some progress going.
Or should I just start finding unformatted classes on The Den, getting author permission, and formatting them?
Just posting to let you guys know I set up the repo to handle hosting the web-forms for latex/bbcode generating.
The first tool under way is the class form. Right now it's the default page, when/if I write more I'll subdivide them.
http://squeeg.github.io/awesomeTome
As I mentioned on the forums I have it in an alpha phase to preview how it's working.
So @Lokathor and I talked a little bit and using his suggestions I made some alterations to the folder and file structure of the project.
Lokathor made a PDF with his idea of the Tome's chapter structure. It's the tome-ref-doc.pdf located in the current-source folder.
Let's get a chapter layout settled on in the next day or two.
The integrated Tome/Srd combat section is probably usable in its current state with a little formatting, but do we want to spruce it up a bit? I'm talking updating the language but leaving the mechanics functionally the same in most cases. For example, standard attacks, full attacks, natural weapons, two weapon fighting, and multiweapon fighting could be made to read much more easily. Right now it's pretty confusing if you want to know how many attacks with what your four-armed monk gets.
Also, turn undead, why is it here? If you want something to reference for class features, shouldn't it be generalized?
Etc. I'm asking because I've written some such things up previously, and if there is interest in doing it I could type it up for review.
I've been busy with single column formatting, and am happy enough with it to ask for feedback. Here's a description, but you can see all of it in the current pdf anyway:
Races have fluff at the top, a few tables of standard data in multicolumn (they're small), and special abilities at the end. I think it's a good use of space and should display well in single column.
Feats are just regular single column. There's a few spacing issues where feats are overseparated when text gets right to the end of the line in the previous feat, but these should otherwise be set.
Spells have standard data floating on the right, with spell text on the left and underneath if it gets long enough. Given the preference for single column, I'm not sure there's a better way to set that up that doesn't waste lots of space. We can get 4-5 spells per page in this format, though short spells have a fair amount of wasted whitespace on the text side. We can fit more if we're willing to cut standard data out of the box (like not showing action unless it's not standard action, or not showing SR unless it's allowed, or cutting duration, etc.).
Feedback and thoughts appreciated.
Are we going to be using Red Rob's work on magic items?
Everyone seems on-board with the idea of skill talents as extensions of skills and a place for non-skills to live. So let's sort a couple of other issues with them, before the work of transcribing them gets underway.
My preferences are below:
I've finally got the skeleton of a race format that I think looks presentable. I used the aasimar as an example. Its currently using badawful description text that I wrote. If the format seems okay, I'll standardize and improve it, and provide an examplerace.tex.
Have you guys run into this?
! pdfTeX error (font expansion): auto expansion is
only possible with scalable fonts.
Are we aiming for phones/tablets, or PC screens, or some specific size of paper so that we could maybe have it printed in a shop, or what?
Basically, on a tablet or phone you want smaller pages and large text so that you can read it properly at all. However, that makes it hard to place tables and figures, and makes it look kinda dumb on a PC screen.
It's not at all trivial to just make both versions, because the pageflow is totally different when you change paper size. If you want tables and figures to be at all placed properly you need to move them around after you've got your text flow determined. So we should pick what we're making, and if we can later make a secondary version later then that'll be nice but not something to count on because it'll honestly be another pile of work on top of the large piles of work we've already arranged for ourselves.
Consensus seems to be to keep existing skills and do mergers. Since Lokathor already has them formatted for LaTeX, we can probably start on the merging and errataing... just as soon as we know what those merges and errata bits are. So let's hash those out here.
Here's some things that have been tossed around the boards for a while that are pretty close to simple skill updates:
And on the subject of binary skills, should we turn binary skills into 3-phase (non-proficient/proficient/master) or 4-phase (non-proficient/proficient/master/grand master) skills instead? Sort of a half-USE setup for skills that don't really scale well.
I'll save my own preferences for a bit on this one.
This is a test issue, to see how the formatting and replying and whatever else works. I could have done it on my fork I guess, but I thought I'd put it where others could play with it if they wanted.
Anyway, while if you'd rather be updating classes or text instead of playing with Git or discussing scope and inclusions, updating any non-updated classes (like Koumei's) seems like a decent way to spend your time :-p
Did we ever get a topic going on TGD about asking folks if they wanted to officially contribute their works into the compilation PDF, and if so, for them to link to which works they'd be find with including and what special copyright entry they might want (if any).
If we haven't done that, we should do that thing.
I was under the impression that third parties were allowed to copywrite their content like WotC does with their boxing-off-of-their-copyrights.
We know we're going to have one of these chapters, and we know it's not going to look drastically different than what we had before. So we might as well start determining exactly what base classes are going in so that we can update and errata and start putting them in their place.
Here's my suggestions from the Den thread (slightly updated), because it seems as good a place to start as any:
For sure:
Possibly:
Since we seem mostly agreed on the basic shape of the skills chapter, and we could get moving on some of that.
So here's a to-do list for skill cleanup:
Anything that is flagged as no errata is still something we should glance at to make sure that the DCs are in the right places before we move it into the current-source folder.
The SKIPs should drop off as discussion in the other thread proceeds. I'll edit in whatever needs to be done for them based on discussion on the other side. I'll also strike through completed things as they get done.
Not sure if we should try to limit comments here to just "doing ###, finished ###" sorts of things or not, but figured I'd toss it out there.
Any thoughts on what we're gonna do with all the monsters? I believe Frank made a (very valid and sensible) post with respect to needing to have the monsters designed first, before anything else happens. In my view, this is quite important, and quite a few things (if I had my druthers) should be changed about them. Here's a preliminary list:
I'd also like to add a few monsters to the whole thing, but that's just me.
The new feats file references file and folder structure that causes it not to compile. feats.orig compiles fine. Do you intend on importing the new structure to the legacysource folder, or was this unintentional?
I have some questions about some of the things that we're doing. Note, this may be technical in places (which I will mark with \begin{technicalbullshit} and \end{technicalbullshit} so that only @ExplosiveRunes and @Lokathor worry about it).
Anyway....
The formatting of the core books is to indent new paragraphs, including class features, except for the paragraph immediately following a header. Is there a reason we aren't using this formatting? It seems like it would help with ability start identification since we're not using alternative colors (due to weirdness with floating tables). I actually prefer to indent things in that style, so I'm wondering why it was changed.
Do we have a section numbering preference? We want numbering to display on chapters, but do we want number to display on class titles? On class subsections? Do we want some sort of parity between sections shown in the ToC and numbered sections? I don't know that the numbers are distracting, but I was thinking about it and wanted to bring it up.
\begin{technicalbullshit}
Why are we using the memoir type instead of the book type? Don't know that I have a preference here, I'm really curious.
Can we not use the special color block formatting package @ExplosiveRunes? You could get similar results by declaring a tabularx or similar table with a single row and column using \rowcolor instead. It's not a big deal, but the current formatting complication seems unnecessary (and it also compiles badly on my setup for technical distro reasons that I can go into upon request).
\end{technicalbullshit}
Now, call me strange or old-fashioned, but I believe that even a work as generic as this needs some kind of 'default' setting for people to play in. It would also help us understand things like the tone of what we're aiming for, as well as what kind of classes/species/monsters/etc we need to (and want to) include. While I don't mind contributing, I'd like to find out what you all think about this and how we should approach it.
While working on the paladin I said I'd do, I realized that I might be doing a bunch of work for no reason. Since we're trying to make a SRD / Tome composite that is accepted by the Den (in so far as they accept anything as a whole really), I thought we might benefit from poling them as to the most acceptable form of the Bard, Ranger, and Paladin. So I was thinking about putting a few polls up to gauge things, these look focused enough to get useful data in addition to normal shit flinging
Anyway, the polls:
Pick your favorite Bard:
Pick your favorite Paladin:
Pick your favorite Ranger:
The following generic options would be appended to each one for completeness:
If there are objections to my putting this up or any strong opinions on inclussion as the official replacement I won't bother with it (because I care more about pleasing people putting in work than people who aren't). So please let me know those things. Most of these will probably fall into a classplosion / ACF appendix sooner or later anyway though, just not be the 'official' replacement in the TRD.
I found this while browsing the Den:
angelfromanotherpin wrote:
A Monk can take the class feature Willow Fist instead of Willow Step.
Willow Fist: A Monk can use their Wisdom mod instead of their Strength mod for damage rolls and for combat maneuvers.
http://tgdmb.com/viewtopic.php?p=164064
Do you guys think it's worth adding to the Tome Monk?
Do we want to include chunks of IGTN's Book of Elements? I've played with it before and think it's on par with the other Tomes quality-wise, and the style and content fit. Including it would be pretty low-overhead since the vast majority of it is classes, feats, spheres, and writeups. The real question is whether we consider the BoE to be a "Tome", and I don't know what the community opinion there is.
I had a "tome compilation" thing of my own, and so when i tried to add the class template stuff to my classes using the \goodfor and \goodbab commands and so on, it showed the table just fine, but then none of the \ifx statements computed properly, and so it always shows low BAB and poor saves.
Does whoever made the class template have any idea of what's going on? Or what I might have forgotten to import or something?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.