Assignments #17
Comments
|
Classes are not a complete TomeRef priority; we already have the ones we need for sure formatted and mostly ready. Same with spells I think, as a result of your upload. Skills are pending merge decisions. Feats are mostly ok, not sure if we want to include any actual SRD but those could maybe use some work. Really though, monsters need some transcription love. MS sent me an initial latex draft of one that I'll upload shortly. If it's solid, you should start mass formatting and importing of those before we start adding bonus content to the project. |
|
What about starting outlines for chapters? @ExplosiveRunes : I noticed the feats had slightly different formatting macros between the initial feats and the outsiders/elementals/undead. Do you know if there was a reason for that? |
|
@SqueeG Probably just legacy formatting. By the time I'd joined the awesomeTome project I was the third generation of commiter to the project, Surgo wasn't even working on it any longer at the time. We could definately standardize them. @Tarkisflux Well, a few things to clarify, then I'll start working.
|
|
That's what I figured, just wasn't sure. We could just run the monsters through a script to strip out feats that no longer exist. edit: Just noticed that @Lokathor 's implementation of spells has a 'spell entry' macro. |
|
The \spellentry command just contains a little bit of text formatting. What I want to do is create a \spell command that has several arguments in it (one for each section of the spells entry), and to somehow index those arguments such that you could generate an index so that it would return the name of the spell instead of the think indexed. For example, I'd want to be able to use a command similar to /makeindex{Wizard 1} to generate a list of all Wizard 1 spells. |
|
@Lokathor or maybe @mrsinister13 will need to weigh in on the LaTeX issues, as I'm not at all qualified to do so. On monster, I'm actually pretty comfortable including legacy SRD feats until such time (if ever) as the monsters are updated to not need them. We could put all of the SRD feats in an appendix even, it's only a few pages. |
|
Actually, equipment could use a bit of transcription as well (which I seem to have overlooked before). So if you wanted to get on that stuff while someone with more LaTeX experience looked over spells and we sorted monsters, that would be good. Specifically:
[Edit] - Permission has been requested to release these under the OGL where necessary. I assume that Sigil's offering up of the weapon system counted as permission though, and I can ask via form PM if it's really necessary ;-) |
|
I can try and tackle the armors tonight. |
|
@Tarkisflux Yeah, that Weapon system is released under OGL as of... now. Yay. If anyone has any comments or suggestions about it I'll gladly incorporate them into it. About monsters and feats. Most monsters have really boring and predictable progressions of feats. If we wanted to phase out legacy feats could we replace them with level-scaling feature packages? That way there won't be a strange dichotomy where we have one set of feats that are good, and one set that sucks. We'd just note that the monster ability packages are not intended to be as powerful or diverse as the feats they replace, but are a tool to enable easy usage of monsters by granting them passive abilities, creatures noteworthy enough to get a name should have this package replaced by actual feats, they are essentially an NPC. Examples: All of the formian just take the dodge-mobility-spring attack-etc feat tree up until the formian queen. Edit: Also noteworthy, because that weapon system changes the names of weapons to genericise them, the weapon proficiencies of classes and races that gain specific weapon proficiencies would need to be rewritten. For example, elven racial proficiency with 'long swords' would need to be changed to proficiency with 'one-handed swords'. |
|
The elf change is a little nitpicky. A table listing names of weapons that fit in each category easily fixes that. Or they're just proficient w/ Long Swords and not other one-handers. :p |
|
The thing on the index of spells, and I was also hoping to move in that direction eventually, is that each spell doesn't have the same spell data. Like, some spells have an "area" and some spells have a "target" and some have an "effect" and so on. So, since most LaTeX commands expect a consistent number of arguments, and setting up variable-argument commands is pretty arcane to me, I split the task of "declaring a spell" into a bunch of sub commands. My plan was that they could set local variables and stuff later on and end up working out I didn't think about it too hard though, since they don't need to be indexed really, since they already appear in the book alphabetically all in the same chapter. |
|
@Lokathor why not just do an extra parameter for that variable field that you specify with the spell? Then "target" or "area" or "effect" or whatever is just one more thing that gets declared and filled into the appropriate spot with formatting. |
|
I can look into optional parameters. I know they're possible under LaTeX. |
|
Because while LaTeX is programmable, it's not what I'd call easily programmable in more complex cases. My Idea was that there'd be a variable for something like "current spell name" and then \spellentry{} would set that and things like \area{} and \target{} would be able to index using the current spell name as part of the index or something. Except the REAL hangup is that LaTeX is not a databasing system, it's a text output system. So using it to make a database is kinda foolhardy. If we want a database of all the spell stuff, that should be another thing. I mean there are ways to generate text output that a database can then read in and the database software can left you sift around and stuff, but that's a side project if anything. In general, it's easier to work with lots of little tiny commands when you're making new commands, the glue them all together later on. Which is why I favored making each section of a spell description's declarations a command that I could change the formatting on later if I needed to. |
|
Alright, here's what I've done. I gave up on having one megahuge \spell command upon finding out that the maximum number of arguments a command can have is 9. I ended up making a series of easy to use commands that will retain the format of the spells, while also indexing them. This implementation requires the imakeidx package, so before the document begins we need to \usepackage[makeindex, splitindex]{imakeidx} and also \makeindex[name=spells](along with whatever other indexes we end up making). These are the commands that make the magic happen:
So, here's an example of a spell formatted using these commands: \renewcommand{\spellname}{Acid Arrow} Finally, here's what the .idx file looks like for just that spell: Unfortunately, I haven't been able to get it to actually print the index. I thing its a problem with my editor though, not the code. My goal is to replace the section of the magic chapter with all of the spell lists with 'index' entries. So we could automate the output of the spell lists. This way, if we ever add new spells, or change spell levels, or add sphere tags, those can be easily included without any work done by hand. This has been a learning process for me, but there are still a few things I need to learn. Mainly how not to print an entire index, but only a subindex (or to break up the commands to index things into different indexes, which is simple enough. Also how to alter the formatting of how indexes get displayed (this looks fairly straight forward). Here are links to the two files I was testing with so you can look at them yourselves:
I know this wasn't a priority, but I learned a lot about latex doing this. |
|
I think you may have misunderstood what I meant above. When I said add a new parameter, I meant having something like \effectentry{Effect} \effecttext{1 arrow of acid}, so that the bolded line that said "Effect" was itself a declared parameter into which you could put "Area" or "Target" or "Targets" or whatever really. That probably makes it not the sort of thing that you can index over, but it does allow you to have one set of code for every spell despite the variable row header (which is basically what the wiki did). Also, fuck yes to automation and indexing. This needs to work for extensibility reasons. |
|
Ah, I see, so you'd want something like.... \newcommand{\aiming}[3]{ Which should let you use \aiming like this \aiming{target if any}{effect if any}{area if any} and not display anything for arguments left blank. I haven't tested this yet, but will later. Edit: Github comment code is weird and refuses to display one of my \s. There are supposed to be three \ before fi on line two, not two. Aside from that it works. |
|
Actually, I was thinking something lower tech (and I just started looking at the code a minute ago so this might be completely stupid or entirely wrongly coded) like... \newcommand{\aiming}[2]{ That makes you specify the type of aiming that you do with it and then the aiming line itself as well. Not sure that's any better though. |
|
Ah, that would work, too. I presently just have a command for each type of aiming (Target/Targets/Effect/Area) each with one argument that outputs nicely. So, \target{has great sales} results in:
While \effect{Ineffectual} results in:
I prefer this because it reduces the amount of manual input when creating a new spell, I mean, it only saves you a word, but it doesn't add any complexity either. I actually prefer it over my three argument version from my previous comment because the individual commands (and your two argument aiming command) will make it very easy to use some simple text manipulation macros to reformat the spells tex files we already have. |
|
This is all very cool, but, again it kinda doesn't actually make a database, it just makes a few extra indexes. Which is okay I guess, but I don't know how useful the bonus indexes would really be.
I don't get why \spell{} is accepting one argument and then not using an argument but ALSO requiring that you use \renewcommand{\spellname}{foo} before you use \spell{}. Why not just have the \spell{} command accept the spell's name as the argument and then have \renewcommand{\spellname}{%1} at the start of it? All the rest ends up looking almost entirely the same as how I had spells setup. The idea is that a spell's LaTeX code looks kinda like a spell's actual spell entry in the book, so that you can more easily see what you're going to get when you're editing. That's a good thing, and I commend you ExplosiveRunes for sticking to the same general idea. |
|
@ExplosiveRunes If you wanted to do one unified command for formatting but have a bunch of more obvious commands that people actually used, could you do a bit of obfuscating? Using your \aiming{}{}{} as an example, something like: \newcommand\targets[1]{ and \newcommand\effect[1]{ and so on. Then you get easy to read and easy to format spell entries, with slightly more complicated background selection stuff going on. Not sure you can pass LaTeX functions like that though. |
|
@Lokathor Why didn't I include \renewcommand{spellname} inside \spell? That's a damn good question, and I'm going to chalk it up to a brainfart. I'd written that code during night school, after an 11 hour shift. On the actual usage of multiple indexes, it's not where I want it to be yet, but since this is a side project it should be okay if it takes me a while to get it working. After doing some (more) research, my current plan is to use xindy and splitidx instead of either makeidx or imakeidx, and to create an index style file that will output indexes in a format that resembles a class spell list. Under this scheme I'd probably want to have indexes for spells, spell lists, spheres, domains. That way when it comes time to list all of those things in the magic chapter, we could literally just: \section{Spell Lists} and so on. It would also mean that when we add a new class to the pdf that has a spell list, we could quickly use the \spellb{Name of Class}{Level of Spell} command in the appropriate spell entries, and the change would generate a spell list in the appropriate chapter. We could also use the \printsubindex command from the splitidx package to print out just that classes spell list somewhere inside that classes entry if we want. Splitidx does have one drawback. Latex can only write to 16 files simultaneously, so splitidx requires you to run a seperate program/script to split the .idx file into all the different indexes, then compile again. This is a minor inconvenience, I feel. @Tarkisflux you can put commands with arguments inside other commands, but unfortunately when using the command, you don't really have a way to pass down anything into those arguments (unless you use preset values, or manually define them or something, which defeats the point) so unfortunately something like that won't work in this situation. Those examples you gave work, technically, but offer no benefit over the versions with no obfustication. |
|
Formatted my weapons system and put it into the current-source structure. The table though are large, and that's always annoying in latex, so each one is currently occupying its own page. |
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?
The text was updated successfully, but these errors were encountered: