Template talk:EnemyCommandList

Perhaps do what the code does?

In the code, monsters only have 8 slots. For those who use more than 8 moves, like Poseidon and Dullahan, they actually use multiple sets (two in Poseidon's case, 3 for Dully). Perhaps consider such an approach? Rolina (talk) 16:09, 3 December 2012 (CST)

I think simply having the one command list extended to 15 sections the way Dkpat did it is the only way we can really do it when we aren't aware of whether or not there are extra possible RNG formulae the game is using in order to consider multiple, separate 8-slot command lists for the same boss. We're really only trying to present to laymen single, full lists of commands used by each monster and, whenever possible, each command's programmed relative chance to be used. We're able to show percentage chances for abilities in most monster pages because most of the normal 8-command lists have straightforward Attack Patterns, such as the one where each of the 8 ability slots represents a 1 out of 8 chance to be used, or the ones in GBA games where the first slot represents a 53 out of 256 chance and so on.

But do we know enough about the coding of the multi-list bosses that we can give the same percentage calculations about those? Do we know that two command lists on a boss are treated as a uniform set of 16 command slots in which all 16 slots have the same probability to be selected? Or do we know that there are some other RNG mechanics that come into play only when there's multiple lists? Knowing the answer to these questions would perhaps tell us whether we should have multiple sets of eight commands instead of one list of fifteen commands. Namely, if a boss' first action in a turn is to randomly choose an ability out of command list A, and the second action is to choose one out of command list B, it would justify having separate sets of eight-command lists on the page. But if it turned out that each slot in each of the three 8-slot command lists for Dullahan represented a simple 1/24 chance, the 15-command list approach is best to show straightforward percentage rates. And it's best to default to a straightforward 15-command list for if there are no available percentage rates to post in the Chance to Use section at all.

By the way, the whole Serpent thing you're showing a picture of is a different issue - that's a unique case where there's five different bosses that are nearly identical to each other in the game code (not counting the two numbered dummy versions) save for different HP regen rates, and each Serpent version has a standard 8-slot command list of its own. Of course, we know that which Serpent version you fight depends on how many Gaia Rock beams of light you shine down on it. The only difference that happens with the move lists in these cases is that the most weakened form of the Serpent has different chances for selecting each of its moves, while the other four versions have command lists that are identical copies of each other. In that case, it's only worth having two separate 8-section ability tables on the Serpent article at most, in order to show the two different sets of percentage chances. Erik the Appreciator (talk) 18:05, 3 December 2012 (CST)

Actually, the Serpent DOES change more than just that - his AI settings change with the weakest one or two versions of him. Basically, my suggestion is to have a similar setup to the editor - basically 2 columns of 4 for each enemy data. Also, this would allow you to better define and describe each individual monster ability below it in greater detail than you would in the table by explaining them below it. This would eliminate the unsightly stretching that'd occur for some of the more complicated abilities. As for the AI settings, the only ones we don't have a solid value on are the multi-enemy data movesets, like with the Doom Dragon, Dully, and Poseidon - but we're getting close in the GSHC to figuring it out. Just a few more things, and then find the time for Atrius to make an official update to the editor.

Either way, my main reason for this is Aesthetic in nature - I like the two tiered version more than the single tiered one. Plus, as added bonus, people can see how it's actually done in the code this way. A fun bit of trivia for those who care.Rolina (talk) 00:59, 4 December 2012 (CST)

Huh, the more you know. Though I'm having a hard time picturing how exactly a two-columns-of-four setup would be more aesthetically appealing than the current setup (which I personally would just as soon keep), or how that would even allow more detail with less "stretching". Maybe you should post a simple table here and fill it up with the data for a boss's set of abilities to show a draft. Erik the Appreciator (talk) 11:49, 4 December 2012 (CST)

Eeeh... I'm... really bad at wiki code. The most I can say is to try and replicate the layout in the screenshot, but for those who have multiple moovepools, mark which movepool is which via a header row (ex: Movepool 1, Movepool 2, Moovepool 3). In the case of the serpent, a second movepool would be listed for the AI changes after a certain number of lights have been lit up. Right now, I see that one long list, and I'm just seeing a lot of wasted space - by condensing it into two rows of four you take better advantage of the horizontal space on the page, and can do a better job of explaining enemy skills below it.Rolina (talk) 09:31, 5 December 2012 (CST)

Attack	6/8 (75%)	Fortify	2/8 (25%)
Standard Physical Attack.		Enemy ability that is a copy of the Standard Defend command which halves all damage the user takes during this turn.

Something like that? ~ dkpat (talk) 10:58, 5 December 2012 (CST)

No quite. Lemme try and see if I can tweak it without breaking it...

Enemy's Attack Table
Attack	1/8	Attack	1/8
Attack	1/8	Attack	1/8
Attack	1/8	Attack	1/8
Fortify	1/8	Fortify	1/8

Attack: Standard Physical Attack.

Fortify: Enemy ability that is a copy of the Standard Defend command which halves all damage the user takes during this turn.

Of course, a table as simple as this one doesn't quite do the format justice, but for more complicated ones it'd give a clearer picture. It'd also give insight as to how the game selects data, again, for those interested in such knowledge. Also consider integrating this, along with the monster's elemental power and levels into its monster data, so as to not need separate tables. This way, you don't have to define elemental power for damage spells, and you don't have to define elemental level for effect only spells (yes, believe it or not, element level works for both accuracy and resist checks for ailment/debuff infliction, based on the element of the skill used. It's not just luck, as it turns out).Rolina (talk) 11:41, 5 December 2012 (CST)

Unfortunately, a table like that is precisely the overly technical approach the wiki (well, I when I came up with this system) tries to avoid visually looking like when serving the primary readerbase only the most practical consolidated information possible. In pretty much the majority of cases, your typical player glancing at the Rat enemy section would only care about the Rat effectively having a 75% chance to Attack and a 25% chance to halve its damage for the turn with Fortify, and would not care to be shown on-screen how the in-game-code internally expresses this with an 8-slot command chart that has Attack in six spots and Fortify in two spots. This "bonus" being shoved in everyone's faces sounds like it'd possibly alienate some readers because of that. I think dkpat's little draft is somewhat closer to what is more appropriate for the wiki's enemy line articles to display, if we're going a two-tiered route.

Now, since almost all enemy command collections are structured just like that, it looks like we'd be better off just having a mechanics article elsewhere on the wiki explaining the technical details about how each enemy's available commands and chances to use them are expressed in 8-slot lists where each slot represents its own incremental chance to be used, and how the RNG interacts with that to produce the chances for what enemies can do in battle. Anyone who looks at that mechanics article will then be able to look at the command list for, say, the Trial Road Mad Plant and be able to discern for themselves that its internal command list would have three 12.5%-chance instances of Maneater, two instances each of Electric Bite and Poisonous Bite, and one instance of Attack. Just as a bit of trivia for those who care, of course.

Okay, so I'd say what we're really trying to determine here is whether to restructure the existing tables to be two-tiered and how to better integrate enemy elemental power ratings. Part of the info-consolidation process that went into the enemy line pages was trimming out any and all elemental power ratings on enemies that would never come into play, like no Mercury power rating for an enemy with no Mercury-aligned attacks. That's why elemental power ratings are only mentioned alongside each ability that uses them. Now, as it turns out, the non-attacking abilities are affected by the enemy's elemental power level. I think the fact every enemy ability associated with an element is affected either by a power rating or a level justifies an "Element" column where all we'd need to show is " 110" for an ability that damages, and " Lvl 7" for an effect-only ability. So, whether the table remains in single-tier rows or is two-tiered, right now I envision that sections should be the name, the consolidated chance-to-use, the Element and innate power/level, the battle effect (including power, range, and secondary effects), and the visual in five columns. (Should battle visual be in its own Visual column instead of the same cell as the battle effect?)

I also disagree about conjoining enemy ability sections to the enemy statistics sections above them because it feels like there could be cases where an article is better served to have them separated, like how the Manticore boss has a blurb above its command list explaining that that command list is cycled through in sequential order rather than being selected randomly. Even if that isn't a good example, how would we know that there won't be some weird case in GS4 where enemies can swap out and exchange different command lists mid-battle? (I think Chaos Chimera is a single enemy with two separate command lists because it changes attack pattern when it is lower on health.) It just feels like we're in better control to deal with oddities if we're able to place the command list separately from the stats bar.

Lastly, since bosses with multiple command lists are such rare cases, I don't think any changes we make to our current setup should be made on account of those existing, especially since we still don't know how exactly the game goes about handing all the tables in relation to each other. Perhaps after just having a 15-command-long list (lacking chance-to-use rates) for the primary readerbase that just wants to see what each possible ability does, there can be a separate section below on the boss page that does show three separate 8-slot tables in the style of the internal coding itself, just to explain why the chance rates in the enemy ability table above can't be figured out like normal enemies. Erik the Appreciator (talk) 14:08, 5 December 2012 (CST)

Elemental Stats Column

So I put in my aforementioned elemental-power-and-levels-this-ability-is-used-by-this-enemy-with column and tested it out on the Kraken page. Raise any suggestions or objections here. Erik the Appreciator (talk) 13:17, 19 April 2013 (CDT)

It might need some fine-tuning, but no outright complaints. The World's Hungriest Paperweight (talk) 19:49, 19 April 2013 (CDT)

I'm not so sure about this column. (I suppose I tl;dr'd your spiel above about the idea.) There might be a way to make it work, but something about how it looks right now just puts me off. ~ dkpat (talk) 21:54, 19 April 2013 (CDT)

By the way, do you know how the template can pad out the cells in the "Elem. Stats used with" column so that the bulleted items in that column on the Kraken page appear the way they do right now - several pixels from the left edge of the cell - but that I wouldn't have to put in &nbsp spacing syntax before each bullet in the content on the page itself? Erik the Appreciator (talk) 22:01, 19 April 2013 (CDT)

There is, I'm not sure the exact width of the padding but there is CSS for that! (and is actually the "proper" way to do spacing) style="padding-left:2px;" If you'd like you can put that in the style for each cell, but there may be a simpler way to do it. I'm going to try to cleanup the code of the template a bit in the near future just so that it is shorter. (and I'd kinda like to keep the variables for color consistent with the other color switching systems we have, so I might change those as well... which would be a headache) ~ dkpat (talk) 22:38, 19 April 2013 (CDT)