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)

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)