an anonymous contributor
  Loading editor
  • From what I saw on the Gangplank Gangplank page, you were trying to work on a template that could flip through more than two instances of text. Though I doubt its applications, I think it's an interesting project, and I could help you with it if you'd like. Right now, the JavaScript behind the template only allows for two instances of text, hence why text3 and text4 were bundled up with text2, and so to create a new text-flipping template you'd also need new JavaScript code.

    Also, if you want to test a new template, I'd recommend first creating it in your own user space before taking it to the mainspace, so your new template would be titled something like User:Vsagent/CustomFlipText. Here's the code I took out of the GP article, minus the article's data:

     <span id="container" class="container" title="Click the text to show more information." style="cursor:help;"><span class="flipText1 active">「 {{{1|{{{text1|*TEXT 1*}}}}}} 」</span><span class="flipText2">「 {{{2|{{{text2|*TEXT 2*}}}}}} </span><br><span class="flipText2"> {{{3|{{{text3|*TEXT 3*}}}}}} </span><br><span class="flipText2"> {{{4|{{{text4|*TEXT 4*}}}}}} 」</span></span>
      Loading editor
    • View all 20 replies
    • You're not making much sense.

      I didn't ask you: so you don't agree? Only then, No, I do (agree) would have made sense.

      I understand that in Jinx's R case it would hide secondary target's values, but do you really think there's an usage problem in applying the template to GP's R?

        Loading editor
    • Apologies for the confusion. What I meant is that ft does already achieve what you wanted to achieve, if you ever wanted to achieve it. I also think bunching up multiple kinds of information under one field is not something that would benefit the mainspace, as it not only makes for not-so-good distribution of information but also messes up with the description-to-leveling correspondence, as was the case in the Jinx article. Gangplank's R has most of its information in the same section, but I still think the current implementation works best.

        Loading editor
    • an anonymous contributor
        Loading editor
  • The world's a bit too politically correct for people who know themselves inside and out.

    Swallow your pride and try to refrain from posting bile on the board if you wish no harm for the project itself. They're good people, but also disgustingly sensitive and naive.

      Loading editor
  • hello, i just corrected an edit you made to malphite in february about brutal strikes

    you added that the splash damage is not amplified by crits, but in fact it is

    please at least test things beforemaking edits like this in the future, lest you spread more disinformation, thanks

      Loading editor
    • an anonymous contributor
        Loading editor
  • You wrote:
    All self-targeted abilities is single-targeted ability but not all single-targeted abilities is self-targeted ability.

    All ally-targeted (or enemy-targeted) abilities is single-targeted ability but not all single-targeted abilities is ally-targeted (or enemy-targeted) ability.

    Self-targeted abilitiy is a member of single-targeted ability. Same as ally-targeted and enemy-targeted. Why don't we join it up with thing containing it? Or why don't you seperate them?

      Loading editor
    • That's how I see it: Self-targeted abilities can be single-targeting or auto-targeting and single-targeted can be self-targeted, ally-targeted (ally-targeted <> self-targeted as in Infuse, Stand United cases) or enemy-targeted. BUT single-targeted can't be also auto-targeted, as an auto-targeted ability acquire the target(s) itself while a single-targeted one requires target input from the user.

      I hope it's understandable.

        Loading editor
    • This reply has been removed
    • Single-targeting is pretty misleading I know. I guess that every ability that was considered aoe was described as multi-targeting before (as I saw in the 1st ability details template), thus the rest, those abilities that require a target to use, were naturally named single-targeted. And auto-targeted (or self-proximity targeted, how they were named back then) were considered skillshots (as I found in the skillshot page history).

      I talked with Shaw Fujikawa to rename it manual-targeting to prevent confusion but realized ground-targeted were also 'manual aimed' so to exclude it, we decide to rename it unit-targeting.

      Also automatic targeting can also be misleading, as the user doesn't go through a process of choosing targets, the AI does that.

        Loading editor
    • an anonymous contributor
        Loading editor
  • Basic definition of a skillshot is that you shoot a projectile that moves in a direction of your choice. Proximity self-targetting abilities does not fit in that description as you neither shoot a projectile that can be dodged, nor choose the direction of cast.

    Vector skillshots weren't removed in my cleanup. Just moved further up in the page.

    If you think proximity self-targetting deserves a page, fair enough but I highly disagree with its inclusion in Skillshot.

      Loading editor
    • I agree that proximity self-targetting should not be included in Skillshot but I disagree with removing true information from the wiki just because it doesn't fit in its page.

        Loading editor
    • an anonymous contributor
        Loading editor
See archived talk page
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message