For Suzette, is it not the min requirement that you need only the base manifest for Guaranteed Poison and Pain?
Topic on Talk:Poison and Pain setting
From Another Eden Wiki
Hrm, yes that could be ambiguous. What do you think about "Equip or Unlock Manifest"? Or would you rather go back to just "Manifest", and leave it to the next column to explain the details?
Also, I hope you don't feel like I was asking *you* not to edit it -> I trust you to do that correctly, I was thinking more along the lines of someone wanting to fix a relatively small point while we are doing so many things. Although for the same reason it's still good to talk about it especially so we don't overwrite each other in the meantime!:-) I should probably be more diligent about finishing going through and verifying the rest of the list, but there are just so many intriguing concepts to add like Curio's cargo query & VCGrasta row (that I did not expect would take *hours* to figure out, in large part b/c the one-liner didn't work and I *had* to use the invoke syntax...), and I was eying the datatables green +/red - icons (e.g. as used in the Cat-a-log at The_Cat_Beyond_its_Territory) b/c those longer words Expand/Collapse don't always work on a smaller screen especially a mobile.
Yeah I think equip manifest is fine.
Good job on Curio row, I believe you when you say you spent time on it. Don't worry too much, I also swap between things on wiki as well. Reasonably in the future, it would be best to grab all skills from the db, which I think can be done since we now have filter for guaranteed and not guaranteed setters though I feel like this is it own task since you may need to create a template for it.
Re Auto-text: I LOVE the skill text from cargo queries yes! Although I also like the option to add manually filled-in text b/c it can handle "new" scenarios so much easier. Right now we have the best of both worlds, which ironically I arrived at by trying to make the text small enough to fit on a mobile screen (especially some of the text for newer skills text is quite long), which was easier than trying to add a filter for that skill text to automatically pick out the relevant parts and either highlight it or filter out the rest.
And if you mean grabbing not just skill text but the very list of characters and their skill names themselves - e.g. everyone who has a "Battle Start" passive, etc., then I whole-heartedly agree. It would be very complicated though. One issue is when there are multiple tables, and then a char appears in an earlier one (e.g. sets it via passive skill), should they then be precluded from a later list (e.g. sets it via active skill, if they *also* set it via a passive one)? Another issue is how those tables would be sorted - perhaps use newness, or even something like the Altema rating just b/c it's kept up to date (it's *not* good, but it could be good *for this purpose*? it's the only thing I'm aware of that is as reliably present as release date, and includes such things as manis and true manis, unless the release of those is similarly recorded to be easily used). And then there's the issue of the skill text - do we give up entirely on it appearing on a mobile screen, or work to automate shortening it, vs. using the manual ones as now, perhaps putting in automatic placeholders until/unless someone adds those for new chars in the future, which if people use the page should be doable. Actually that is a more general point that could be re-used elsewhere, which could work by transcluding in a more simple page that is just character name and manual text, to make it easier for people to edit without being put off by seeing the internal coding. So yeah, an ENORMOUS epic task to do all of those together.
I did try to make a template and applied it to Chiyo AS. Couldn't fully follow the top right of skill collapse but other than that, do you think it is okay to apply to all characters to simplify the page?
Lets hold off until we finish designing it - e.g. it affects the table header above it, somehow, although in looking at the template code I can't immediately see how or why, but it makes it ~10x taller, with Skill & Effects aligned top-center even while Character(s) and Requirements remain middle-center (shows up that way in multiple browsers).
Though you are awesome and way ahead of me: I totally agree that having the styles being directly embedded like I did was only a temporary step but that it MUST be offloaded to a template, since we want both consistency and to allow users to add new instances later on more easily. It may have looked good on the outside, but the internal design was a mess:-).
Don't be fooled by the superficial appearance of similarity in the old vs. new collapsible [+/-]s: the ones inside the tables are an entirely new style of encoding, which I learned by reverse engineering / deconstructing the character skill coding to use collapsible elements to daisy-chain swapping out any series of blocks with the next block in the chain. To include them in this new template, we'll need to use a variable to count the number of instances and thus provide a unique identifier for each block that we want to swap out, as the character skill row template does. After that, it's a simpler matter to fix its' position in the table. In return for all that, we get additional screen real estate by deleting the manual text when the auto text is displayed, which imho is 100% worth all that effort, b/c vertical space on a mobile really is at a premium.
But this is a great start towards using a template across multiple pages and even to improve just this one - thanks, I love it! (or, you know, will when we get it perfected:-).
Another example where manual text is helpful is Serge's skill Shining, which the skill text says in words can be adjusted to other elements, but the icon seems to tell a different story in it being a flat non-elemental skill. Cynthia's skills instead use the FEWW coloration, so this is an inconsistency in how those are handled on the two pages, and then a third inconsistency is that the tooltip says only Fire, Earth, Water and Wind, while her skill text now adds Thunder and Crystal. Although Serge's is literally different in that it can be a non-elemental skill - so uh...a NFEWW perhaps?:-P - while hers I would guess never could (unless some new stance would allow that somehow?). So this is a lot of complexity that somehow, someway needs to be conveyed to the user, and using pictures helps a great deal to aid in scanning through the list quickly to find something worth reading more details about in the text.
The multi elements icon is from the game assets (WFS made it but never use it) so it could be applied to Serge's skills and the text be adjusted accordingly. Cynthia's skill uses the wind icon in-game but the icon was used to make it easier to realize it could be for other elements
Speaking of, uh oh...something's wrong now on his page, since I no longer see "Shining" at all. The skill name is still listed in his page itself, and the Shining page still reciprocally says that Serge has it, but it no longer visually shows on Serge (occurs in multiple browsers). Do you see that - where only 6 skills are listed for him?
Anyway, my original point was to use the skill coloration as another example that the manual text here "adds" something to the page, which a mere automated query would find it extremely hard pressed to do, even if it did go to all the trouble (hehe, using NLP?:-) of automatically extracting and displaying only the relevant portion of the skill. Although I do love how we now offer the option to display the full if the user wants, without having to go to another page and return to continue to browse -> that may help with the team-building process by providing a better way to select which to use.
