Talk:Epic Path: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 8: | Line 8: | ||
I agree. As a matter of fact, would it be possible to not list those at all in the displayed blueprint, and give a link out instead? heck, it could always be the same link to an aggregation page, for all I care. that info is not terribly useful in front of your face, but providing a link to go look it up quickly would be useful | I agree. As a matter of fact, would it be possible to not list those at all in the displayed blueprint, and give a link out instead? heck, it could always be the same link to an aggregation page, for all I care. that info is not terribly useful in front of your face, but providing a link to go look it up quickly would be useful | ||
(RD) hmm, I actually really like having the list of immunities and weaknesses right in the monster, I just don't want 6 subtypes' worth of immunities and weaknesses listed, ever. It would be longer than the rest of the monster entry. However, for JUST type/subtype, I think it's useful info to have attached to the monster. It's not the sort of thing I'm ever likely to memorize, and I hate clicking through to stuff if I don't have to (what if I want to print it out?). | |||
(RD) However, if you wanted to get together to look things over and see if we could present the information more concisely, I'd be open to that. | |||
* also, cargo is broken as hell, and I'm pretty much thinking we should give up on it. | * also, cargo is broken as hell, and I'm pretty much thinking we should give up on it. | ||
Line 13: | Line 16: | ||
uhoh. dangit! I was getting really excited about the capabilities there. :( | uhoh. dangit! I was getting really excited about the capabilities there. :( | ||
:* I haven't completely given up on Cargo yet, but it's really horked right now, so my next steps are: | |||
::* ask Rick to purge all the table data for cargo directly from the database (server-side, not wiki-side). | |||
::* cull as many fields out of the monster template as possible, without compromising any functionality, or forcing us to (immediately) fix any monsters. | |||
:::* This will be necessary if we ever want Cargo to work, since 450 columns is apparently more than cargo can handle, by a significant margin. | |||
:::* Plus, it makes me happy to cut things down a bit; the template is needlessly bloated. | |||
:* to that end, as I mentioned last night, I want to replace all the "nudge" fields in the special abilities with #expr (math) and variables directly in the text of the description of the special abilities. This will require some manual reviews of each monster, and once done, I can delete those fields forever!!! | |||
::* This means a modified variable will look something like this: <nowiki>{{#expr:{{#var:To-Hit}}+3}}</nowiki>. | |||
:* however, the damage fields are oddballs, because they're not numbers, but text. Namely, "3d6+2" isn't a number, so you can't alter it with #expr. | |||
::* we could convert them from numbers to dice after the #expr, which would look like this: <nowiki>{{d6-dmg|transcludesection={{#expr:{{#var:Alpha-Dmg}}+4}}}}</nowiki>. This gives us the power to choose which die-size the damage uses, if we care, and we can use any standard math operand (+, -, *, or /) to manipulate the variable's base value. | |||
::* alternatively, I could change the damage numbers from variables to sub-templates, which you call to insert a damage number. The only parameter on the template (other than the name of the template itself), would be a numeric nudge value of the number of CR's you wanted to modify the damage value by, and it's completely optional. Example: <nowiki>{{Template:Ranged-Damage|-2}}</nowiki> would give the ranged damage for a monster 2 CR's lower than the monster you use this template in. This seems to me to keep things as close to how they currently work as possible. The die-size would be fixed based on the damage type being called (swifts use d6's, standards use d8s, alphas use d10's, etc.). | |||
::* Do you care which option we use? does one appear easier/more intuitive/more useful than the other? | |||
==Stateless Time== | ==Stateless Time== |