Template talk:EnemyCommandList

Perhaps do what the code does?
http://i14.photobucket.com/albums/a314/acidadept/SampleExample.png

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)