Forums › English Language Forums › General › Wiki Editors

Search

"Standardization of Damage Tables" discussion

17 replies [Last post]
Fri, 07/29/2011 - 04:07
Sk-Tactics

I was hoping to standardize the damage tables in the wiki but there are several issues...
Would like some input/suggestion on how we should proceed.
Erm... Please provide the reasons & underlying rationale behind your suggestion.

1. Monsters that take extra / less damage than usual. (Most notably gremlin menders)

  • Option 1: Include an extra section inside each table dedicated to each of these inconsiderate monsters. (see proto gun's page)
    Pros:
    Easier for other people to contribute. One look at the page & they will know that menders take extra damage & they will have to split up their values accordingly.
    With enough data, someone might find out that menders consistently take x% more damage & include this info in the mender's page.
    Cons:
    It will be a lot of work. Would take 2~3 runs (maybe more) thru each stratum to get all the necessary data.
    We might run into more of these inconsiderate bastards in future.
    We may have to redo some of the damage tables since we do not know whether or not they include menders.
  • Option 2: Discard the data on the Main Page, but leave a record on the Talk Page. (see zapper's page for example)
    Pros:
    Cleaner, shorter table.
    Less work to be done. Only 1 run needed per stratum. Table can be considered "completed" w/o having ALL the damage values from menders.
    Flexible enough to be extended later on if we change our minds.
    Cons:
    New wiki editors who doesn't know enough about reading the talk page might decide to be "helpful" & add in the values into the table.
    While someone might eventually figure out exactly what % of extra damage menders take, its a bit harder to do so since the data is hidden & incomplete.
  • Option 3: Include the data inside the min/max values in each stratum as & when we encounter them.
    Pros:
    Least work overall.
    No barrier to entry for new wiki editors. People can contribute as & when they encounter a new min/max value in a stratum.
    Cons:
    Data is somewhat inaccurate. We won't know whether the table is completed or up to date when there is a change.
    We won't be able to figure out whether there is a "pattern" to the extra damage.

*Note* Regarding option 3, the rationale behind it is that for most people, a few points of damage does not really make any difference. The important thing that they want to know is how the weapon perform relative to other weapons. Therefore, it should be given due consideration even though the idea of inaccurate data is kind of repulsive to us "OCD types".

2. Special Damage (Fire, Freeze & Shock), & how some monsters within same family seem to take different amounts of damage from them.

  • Option 1: Ignore it altogether.
    Pros:
    Less work, less headaches.
    Cons:
    Less information available.
  • Option 2: Add an extra row for the special damage, include the min/max values inside. (see Cryotech Alchemer's page)
    Pros:
    Cleaner. A LOT cleaner. I don't even want to contemplate having 1 separate section for each monster in the damage table.
    Less work than option 3.
    Cons:
    Kind of inaccurate. Won't know whether values are "completed."
    Large range between min/max values for weapons that does normal damage but inflict status.
  • Option 3: Do not include the special damage in the weapon's page but create a new damage table with a section for each monster in the status' page.
    Pros:
    Consolidation. Special damage seem to be affected by "grade" (weak, moderate, strong) rather than weapon anyway.
    Work is divided. Sword/Bomb/Gun users can all contribute to the damage table in the status page as long as their weapon inflict that status.
    Cons:
    A lot of work. (Although I won't be the one doing it)
    Users have to navigate extra pages to get the "Real" damage done by status inflicting weapons.

3. Decreasing damage values in a stratum. How should we express them?

  • Stun gun's charge attack does 19 dmg in Depth 1, 21 dmg in Depth 2, and 20 dmg in Depth 3.
    Should we express the values as "19 - 20" or "19 - 21" in stratum 1?
  • Its basic attack does 11 dmg in Depth 4, 10 dmg in Depth 5, and 10 dmg in Depth 6.
    Should we express the values as "11 - 10" or "10 - 11" in stratum 2?

Your thoughts?

Sat, 07/30/2011 - 16:48
#1
culture
Legacy Username
Good ideas

Issue 1: Menders

I like Option 1. It is easy to understand, it will add an additional section to the tables but I think it will be informative for people who are looking for mender sniping weapons.

Issue 2: Status Damage
The data needs to be in the wiki somehow, but what would satisfy people's need for knowledge while not being too complicated?

Shock is super simple since it does pure elemental damage rather than a special status damage to monsters. Option 2 works perfectly for shock.

The other status types are more complicated. Freeze does 5 magnitudes of damage to monsters depending on the specific monster, not just the family. (Freeze might actually be 6 values, need more data to know for sure.) Fire has 6 values. Option 2 would be most complete but it will be a giant table. Might be the only option though.

Option 3 won't really work well, the descriptors "weak", "moderate", etc. are arbitrary. "Weak fire" on one weapon doesn't equal "weak fire" on another.

Another annoying tidbit about status damage is their star nerfing... Ash of Agni shares status damage will all the bombs in the fiery vaporizor line, but only in the first tier. Lower star bombs are nerfed dramatically at different strata.

No idea what to do with Poison >_<

Possible solution:
One way to show this data is to just list the min/max damage at the beginning and end of each strata on the weapon page. Then on the monster pages we can indicate their relative resistance to a status. Like Zombies would have a negative fire resistance, whereas Kats would be very resistant. But they would share the same strong freeze resistance.

That way you know that Zombies should be set on fire, Kats not so much. And don't expect a ton of damage from freeze on either.

Issue 3: Decreasing damage
I really think it should stick to first/last in the strata rather than min/max. Specifically this shows when the weapon begins losing potency. Looking at Khorovod's hit 1 in the last three strata:

First/Last shows:
111-115 169-215 229-225
Min/Max shows:
111-115 169-215 225-229

First/Last shows that damage degrades after Depth 24 whereas Min/Max obfuscates this info. It is weird that the damage decreases after a point, it even looks like a typo. On the weapons where this happens I try to add a note in the damage description such as "Basic attack damage does not increase after Depth 24." to alleviate some of the confusion, also that is a very important aspect of the weapon when deciding what to use in the last strata.

Sun, 07/31/2011 - 16:05
#2
Trias's picture
Trias
Issue 1: There are actually

Issue 1:
There are actually quite a few monsters that take different amounts of damage. These include, royal jelly minis, green jelly minis, ?rock jellys?, and probably more. I don't think it is an option to collect the damage values for these monsters for all weapons and put them on the weapons pages. (i.e. option 1 is out of the question IMHO)

It is probably better to just mention on the relevant monster page, that the monster in question takes more damage than other monsters on the same level.

Issue 2:
Damage done by status conditions is best collected on the status condition pages. On the weapon pages one can simply say that weapon XXX has a chance of causing strong fire (say) with a wikilink on strong fire linking to the damage section of the fire page.

Issue 3:

It think it should remain in the first/last level format for the reason culture mentions.

Sun, 07/31/2011 - 16:05
#3
Trias's picture
Trias
Issue 1: There are actually

Issue 1:
There are actually quite a few monsters that take different amounts of damage. These include, royal jelly minis, green jelly minis, ?rock jellys?, and probably more. I don't think it is an option to collect the damage values for these monsters for all weapons and put them on the weapons pages. (i.e. option 1 is out of the question IMHO)

It is probably better to just mention on the relevant monster page, that the monster in question takes more damage than other monsters on the same level.

Issue 2:
Damage done by status conditions is best collected on the status condition pages. On the weapon pages one can simply say that weapon XXX has a chance of causing strong fire (say) with a wikilink on strong fire linking to the damage section of the fire page.

Issue 3:

It think it should remain in the first/last level format for the reason culture mentions.

Tue, 08/09/2011 - 13:02
#4
Sk-Tactics
Conclusion / follow up

Well, it has been over a week since the last reply so its time to conclude this & move on.
(heh, guess my big wall of text turned everybody off.)

Here is what I'm going to do:

Issue 1: Menders & other damage oddities.
Will add an extra section in the damage table dedicated to menders (and ONLY menders).

Reasons being:
1) I believe that Menders only take extra damage from weapons that does "Normal" damage, so it's not a lot of work.
2) The information provided is "useful". We can compare Sentenza's damage with Valiance's vs menders.
3) Some people are already providing this info. I'm not keen on removing info that other contributors have put "effort" into.
4) Mini Jellies only appear in Royal Jelly Palace, Strata 4. Think we can ignore them.

In addition, I agree with Trias in that we should mention this "damage anomaly" in the relevant monster's page.

Issue 3: Damage format - Min/Max or First/Last?
Will standardize to First/Last format. (Although I personally prefer min/max)

Reasons:
1) Existing damage tables that wasn't done by me all seem to use the First/Last format, plus both culture & Trias agreed unanimously on the First/Last format, so I guess its a majority decision.

However, I would like to rephrase the table description.
"The following damage blah blah blah, and listed as a range found from the first TO last floor of each stratum." implies min/max.
I suggest changing it to "listed as the damage dealt on the first AND last floor of each stratum." to avoid confusion.

Issue 2: Status Damage
I believe that the best way would be to implement it in 2 "phases".

    Phase 1:
  • Add an extra row in each weapon's damage table & provide the approx min/max status damage values.
    (see Firotech Alchemer's page for example)
  • Include a detailed status damage table inside each weapon's discussion page.
    Have done several status damage tables (plain & rainbow colored) on my userpage. you can check my sandbox for an example. There's a Fire damage table with some values at the bottem.
    Phase 2:
  • Combine the raw damage values from the different weapons. (Discard values that are due to weapon star/tier nerfing)
  • Create a Status Damage Table in the status condition pages.
Reasons for doing it this way:
1) Right now, we do not have enough data to decide whether phase 2 is feasible.
2) Need to collect values for all weapons & against all monsters before we can be 100% certain & this could take a long time.
3) Leaving the latest min/max values on the damage tables ensure that wiki users are not "starved" of info in the meantime.
4) In the event that if all of us left the "project", the raw data are left in the wiki for future users to take it up again.

Will start implementing this / standardizing the damage tables to the "agreed" format.
(I seem to be the only one doing the agreeing)

Sun, 08/14/2011 - 11:18
#5
Sk-Tactics
Bummer....

http://forums.spiralknights.com/en/node/20474

Bugfix Patch - August 11, 2011
* Gremlin menders have had their normal defense increased and their health decreased.

Get ready for another major round of wiki editing......

Update:
Have tested several T1 & T2 menders with Blaster & Super Stun Gun, they now take the same damage as other monsters.
I shall remove the "Vs Menders" section from the damage tables & move any existing values to the discussion page as a record. (In case OOO change their mind again.)

Tue, 08/16/2011 - 02:33
#6
Trias's picture
Trias
Collapsible damage tables:

If made a prototype of a damage table with an integrated hide/show button on my sandbox. http://wiki.spiralknights.com/User:Trias/sandbox#Damage

Compare to http://wiki.spiralknights.com/Divine_Avenger#Damage.

1. Should this be implemented as a standard for the damage tables?
2. If so, what should the default state be? collapsed or uncollapsed?
3. How should the table header be formatted?

Tue, 08/16/2011 - 08:14
#7
Sk-Tactics
My Opinion.

Erm... unfortunately, I'm not a fan of using show/hide on the tables.... I vote No. :-)
Personally, I think most people are able to parse/scroll/glance through the table faster than they can click "show/hide".

However, I think Trias' implementation is superior to the current one we have on the wiki.
(Does not look "out of place" & does not "shrink" the actual table.)

If implemented, default state should be collapsed.
Uncollapsed tables defeat the purpose of implementing them as people can scroll past the table faster than they can click "hide".

If implemented, Table header should be "{{PAGENAME}}'s Damage Table". Can't think of anything better. :-)

Have invited user:Oldmcdonald over to give his opinions.
(He has been adding show/hide to the wiki so I guess maybe he can offer a counter argument on why we should use them.)

Wed, 08/17/2011 - 00:43
#8
Trias's picture
Trias
I'm not a fan

I'm not much a fan of using hide/show either, but people have been putting the damage tables in hide/show containers none the same. Which, IMHO, looks terribad. An integrated solution at least looks a lot slicker.

Mon, 08/22/2011 - 06:32
#9
Sk-Tactics
Well, I'm not an air conditioner either... ;-)

It has been almost a week & there's no feedback from other users....
How about we ninja the change in?

I suggest changing Template:SKDamageTable to the new version (default state uncollapsed).
We can set the parameter to "collapsed" when manually removing the old show/hide code from weapons that have them.

This way, there will be minimum change to the current status quo.
(weapons with show/hide gets collapsed tables, weapons w/o show/hide get full tables.)
Not very "standardized" though.....

Mon, 08/22/2011 - 18:17
#10
Equinox's picture
Equinox
Game Master
That sounds fine. I may be

That sounds fine. I may be able to help remove the show/hide template code this week (if not this week, this weekend), but feel free to work on it if you're already editing a page!

Tue, 08/23/2011 - 01:04
#11
Trias's picture
Trias
OK. I have recoded the

OK.

I have recoded the templates to allow collapsible tables.

The current default behaviour is for damage tables to be collapsible but uncollapsed.

This can be overridden by settting the "|collapsible=no" or "|state=collapsed" parameter.

What remains to be done is to remove the existing showhide templates and set those damage tables to be collapsed by default.

(On a related note. Should the formating of the showhide template be adjusted to match the overall SK theme of the wiki?)

Tue, 08/23/2011 - 10:38
#12
Sk-Tactics
Done! (^^)/

Have gone through all the weapons & removed the old show/hide templates. :-)
Not sure what you mean by "Should the formating of the showhide template be adjusted to match the overall SK theme of the wiki?
Elaborate please?

Minor bugs:
1) When clicking on the show/hide link, browser will automatically jump to top of page.
This did not happen when viewing this page: http://en.wikipedia.org/wiki/Help:Collapsing
(I was under the impression that the underlying code is the same)

2) When using certain browsers, header row will shrink to a single cell when table is uncollapsed. (Firefox 3.6.20 unaffected)
See images:
IE Collapsed
IE Uncollapsed
(Affected browsers are: Steam in-game browser, IE, safari & chrome)

3) Irregular cell height for some weapons. (Autogun series are probably the worst offenders)
Can probably be solved by widening the table a bit.

Tue, 08/23/2011 - 13:11
#13
Trias's picture
Trias
hmmm

1) That is weird. The implementation is the same. (In fact copy/pasting the example from there to here produces the same problem.) The only difference I can think of is the version of the wiki software used. (The version used here is outdated.)
2) It appears that some browser don't support the colspan=0 option. If implemented a work around by setting the colspan for the header to 7 explicitly. (This may cause problems if using the SKWindow2 template to create other tables with headers, but currently this is not the case.)
3) I've bumped up the width of the table to 50 em. This seems the fix the wrapping problems for all cases I could find.

Wed, 08/24/2011 - 02:55
#14
Trias's picture
Trias
It appears that my suspicion

It appears that my suspicion was correct. The function "killEvt()" used to cancel the click on the link is not defined in mediawiki versions before 1.16 (SK uses 1.15.3).

Apparently we are not the first mediawiki users to have this problem. See: http://www.mwusers.com/forums/showthread.php?15662-problem-with-collapsi...

The problem can be solved by adding the following code to the http://wiki.spiralknights.com/MediaWiki:Common.js file:


window.killEvt = function( evt ) {
evt = evt || window.event || window.Event; // W3C, IE, Netscape
if ( typeof ( evt.preventDefault ) != 'undefined' ) {
evt.preventDefault(); // Don't follow the link
evt.stopPropagation();
} else {
evt.cancelBubble = true; // IE
}
return false; // Don't follow the link (IE)
}

(For good reasons) that file is protected. Does equinox have admin rights on the wiki?

Wed, 08/24/2011 - 20:53
#15
Equinox's picture
Equinox
Game Master
I've added it, didn't have

I've added it, didn't have time to test it though. Let me know if that makes it work.

Wed, 08/24/2011 - 22:47
#16
Trias's picture
Trias
It seems that worked. Thanks

It seems that worked. Thanks

Sat, 08/27/2011 - 16:22
#17
Jeffreysgf's picture
Jeffreysgf
Just a thought

If Monsters do still have difffering damages, perhaps include a page such as PAGENAME/damage, with a link to it from the main page, with all the different damages recorded (and maybe the date it was recorded).

Powered by Drupal, an open source content management system