Talk:3.5e Races

Nav Page and Properties

Gonna clean this up soon. The info on the page is pretty good for hunting down a race as is, and about the only thing I can think to add to it is a Racial Stat Mod column (not possible with current properties)

The properties populated on the race pages right now are 3e Creature Subtype, 3e Creature Type, 3e ECL, 3e Favored Class, 3e Level Adjustment, 3e Size, and 3e Race Description as well as some entirely too specific stat mod properties. These probably need to be bot edited with Creature Subtype and Creature Type merged into the Type property (that's how it is in other places anyway, I'm not sure I like it though), Favored Class, Level Adjustment, Size, and Summary. The annoyingly specific stat mod properties can be merged into a Racial Stat Modifiers property, and then stuck on the nav table. ECL should probably be removed from the race pages it's on unless they include a monster write up. I can't think of any subcategories that would be necessary for races, and we can purge all of the LA categories that we presently have when the property is properly filled out. Am I missing anything? Any objections? - TarkisFlux 04:31, October 8, 2009 (UTC)

I can probably fill in a story for you: Way back on paleowiki, I noticed that LA 7 races were formatted differently (all 2 of them). Turns out it was an experiment to add SMW properties to all pages. Well, I took the initiative to add these properties on most races I made at the time, despite it not being implemented anywhere else. That said, the system never got the attention it needed to work, so, there are some kinks, and now those kinks need to be fixed. Definitely un-edition the properties with a bot to sanitize the ones currently implemented. Make sure the new properties are added in to the preload too. Updating races will have to be done manually probably, since there are probably a lot of uniformity differences among all the race pages. Anyways, ramblings aside. I feel ECL should stay. Several races have racial HD (and this seems to be a trend toward using racial HD, even in conjunction with LA). While it would be awesome to be able to search specifically for a race with such and such score to an ability score (and I'm not sure if that was anything planned or not), it doesn't work for races with odd things like "pick a +2 and -2 of your choice" for ability modifiers. A single property for ability scores should work fine. With all that, that pesky template at the top of races that was used for the old wiki can be removed as well. Oh, and do we need a property for size? --Ganteka Future 06:25, October 8, 2009 (UTC)

Just a note on redoing this page -- there should be one page. One. Not a page per LA -- that sort of shit should just show up in the table. Surgo 12:11, October 8, 2009 (UTC)

Absolutely. That can go in the table and be sortable and we'll be fine, it's not worth doing sub pages for them. The LA categories can then be purged as redundant and worthless. - TarkisFlux 16:51, October 8, 2009 (UTC)

Gan - I'm still not sure why you want ECL to stay as a property when the race doesn't have a monster write up in it... do you just want to show that it has some number of racial hit dice greater than 0 that may or may not match its ECL? Most of the races in the list have an ECL = LA +1 and don't offer racial hit dice, your deathly asutas does offer racial hit dice, but does so by offering racial class levels and so doesn't list an LA. I think I'd rather have just an LA +6 on something like yours, with a variant +0 and progression that isn't recorded in the properties and doesn't show up in the table except maybe in the summary, for ease of reference and clarity.

As for ability scores, we can do it like we do skills right now and just have a string property that we assign multiple values to. They will all show in the table, and you can sort by them, and when we get the full semantic Special:BrowseData up they will even be text searchable (though you could do custom tables for it already anyway, it's just more of a pain). The +2 / -2 any stat ones will just be an entry that links to the generic SRD stat page instead of a specific stat section and isn't any harder to set as the property value than anything else. In the preloads, it'll probably look like the skills do for the classes (with the exception that you need to set numbers) in that you just delete the ones you aren't using for the race. Should be pretty easy actually, just time consuming. - TarkisFlux 18:07, October 8, 2009 (UTC)

Well Tarkis, LA is really only half the story with race power. Sure, a vast majority of races are just LA races with no HD. While, as the example, deathly asutas use a racial progression to achieve its full racial power, it doesn't have LA, so listing it as LA +6 is grossly inaccurate. Listing it as LA 0 is closer to fair, as it can be used as an LA 0 race with the variant, but then, I think for the time being, I'm the only one venturing into racial progression territory for races (since there are problems inherent with its design philosophy). Anyways, before I get too distracted, I suppose I should mention that there are races that have both LA and racial HD (and don't use racial HD progressions). Uberich have 4 racial HD and LA 1, being ECL 5. Not listing both ECL and LA is just going to be troublesome for people doing searches. Yeah, in the past, I've gotten a lot of funny remarks from people about the deathly asutas, mostly along the lines of "there is no way this has no LA" and "are you out of your mind?" before I point out the ECL when people do searches by LA. Now I've lost my train of thought. Did any of that make sense? --Ganteka Future 18:27, October 9, 2009 (UTC)

It makes sense I guess... it just hurts my brain. I had forgotten about (or actively ignored) the stupid rule where racial hit dice count the same as class levels for determining minimum xp levels. So yeah, you need account for ECL and LA when making a character for a game. We should probably keep the ECL in the table and go through the races to make sure that the ECLs for everything are accurate. But not now, I need to go have a cry about this rule first. - TarkisFlux 23:29, October 9, 2009 (UTC)

So, took a bit more time to wrap my head around that nonsense... turns out it was actively ignored and I had just gone with the SGT mantra that CR = character level. The CR adjustments from near useless racial hit dice (as seen here) are not the same as the ECL adjustments, and the CR adjustment had become what I used for racial hit dice in my games. Which isn't RAW for character creation and probably isn't the way the majority of people look on races with racial hit dice. The Uberlich sidesteps that issue by giving the race 4 levels of psion / wilder power advancement to go along with it for free, but that's really just a bonus that makes the 4 ECL less painful. Rant aside, ECL stays in the list, but I still hate that it's somehow separate from LA. Just another piece of the mess that is playable monsters in this game. - TarkisFlux 00:26, October 10, 2009 (UTC)

Still mulling over what to do with subtypes, since whatever we do with them needs to be portable to spells and powers as well if we want to keep the same properties (which we do). I think the best way to do it is to just have a property for each of them and move on, but we could also just have the type property and append "Subtype" to any subtypes in it. - TarkisFlux 01:24, November 4, 2009 (UTC)

I lopped the "3e" off the starts of the properties on the table (to continue with edition-less properties) as well as switched the "race description" property out for the more standard "summary". Anyhow, with properties now, we don't need Template:x0 anymore. Just making a note here that it is to be removed from all existing pages (taking it off the preload in a moment as well). It would be cool if everyone updated their races to include these properties, but if not, I'll be trying to get them done as I rate stuff. I'm still curious as to how we should list ability score adjustments on the table, if at all. It is handy to have on the table, but I'm not sure what the property is for it, if there is one at all. --Ganteka Future 20:18, December 4, 2009 (UTC)

Thanks for reminding me. Too many things going right now :-/. You want Property:Racial Ability Adjustments to stick all of the adjustments in, rather than one for each stat. I'll go add it to the table. - TarkisFlux 20:37, December 4, 2009 (UTC)

Thank goodness for that (being a catchall property), and it's now in the preload too. Thanks dude. --Ganteka Future 20:52, December 4, 2009 (UTC)

Thanks for your amazon race being a non-standard "choose one mod race". Made me go back a few times to figure out the best way to work with the property and get it set on the preload. For search purposes, we will want to have each mod / choice of mods as their own entry in the property, so we'll want [[prop::mod1]], [[prop::mod2]] for the articles, or the property link that I put up in the preload for linking stat mods to stat entries. Your choose one thing has its own bizarre setup so that the 'or' shows up in the property in the right place. It messes with search a bit, but it makes the property entry non-misleading. - TarkisFlux 21:10, December 4, 2009 (UTC)

CSSification

The default SMW tables really clash with our pages. Simply overriding the color styles in our CSS would be a good start, but I would love to see these tables look like the zebra tables (for a good overall consistency). Is there any way to add a CSS class to each alternating row in a SMW table like we did with regular tables? --Andrew Arnott (talk, email) 14:54, October 8, 2009 (UTC)

Yes, just put class="d20 sortable". Sortable actually adds stripes itself, I just haven't gotten that to work yet. Also, instead of |format=table, use |format=template and |template=Table Row (thus wrapping the entire thing in {| class="sortable d20" |}Surgo 17:32, October 8, 2009 (UTC)

No more adding Zebra then... does it only stripe once, or does it update the striping on sort? If you pop over to 3.5e Prestige Classes and sort by length or minimum level you'll notice the stripes bunching up because they're still striped per the initial name sort. It's not really a big deal, but it is a bit odd looking. - TarkisFlux 17:54, October 8, 2009 (UTC)

Sortable updates the stripes after you sort, so long as you do not add Zebra. I haven't yet gotten sortable's striping to work for some reason, but it will soon -- so keep making things sortable. Surgo 18:21, October 8, 2009 (UTC)

(Copied from Surgo's talk page since the braoder discussion is also here) The table row template is working fine and passing everything appropriately. But when you click on "Further Results..." it moves to a special query page and continues displaying the results formatted with the table row template and in table format, but does not pass the table wrapper. So instead of getting a nice looking table, we get confusing table syntax results that bump up against each other. Can we just update the css of the regular ask tables instead of sticking the results in a wrapper? Or can we update the special querry pages to put the results in a table wrapper? Or am I going to have to hard code the tables to be 1) really really long or 2) decent size with hard coded additional pages using offsets? - TarkisFlux 16:11, October 9, 2009 (UTC)

Is there any way to include custom javascript on wiki pages? That could solve the reordering problems. --Andrew Arnott (talk, email) 15:36, October 10, 2009 (UTC)

I solved this problem last night. Surgo 15:39, October 10, 2009 (UTC)