Multiverse Feedback: Recent Activity
| Multiverse Feedback: Cardlist | Visual spoiler | Export | Booster | Comments | Search | Recent activity |
| Mechanics | Upcoming releases | Skeleton |
Recent updates to Multiverse Feedback: (Generated at 2025-10-28 06:58:29)
Gosh! Yep, reproduced. It only affects searching by comments. More precisely, the bug is that technically, this will only find comments on the cardset as a whole, not comments on individual cards within the cardset. E.g. you can search for comments I made on the Community Set mentioning "flying" and it finds 3 hits.
That behaviour is clearly a bug though - nobody's going to want to use the search page to find comments by a particularly user on the cardset as a whole.
I'll get this fixed.
Standarizing that would be cool if you have plans in mind. But just for the sealed pool, ordering/filtering anything other than color would be overkill, I guess. :P
That's a pretty sensible idea. It's partly a duplicate of Unusual boosters / Multiple boosters, but also asking for the ability to sort the resulting cards.
I've been musing about expanding the visual spoiler functionality to apply to any kind of selection of cards, and this would be a natural application of that. So I think this would fit in quite nicely with developments I've got planned.
Yes, you can open a booster six times but you don't have all the information easily available.
Hmmmmm.
Very nice idea. It'd make a lot of sense as a user preference. I could also see it as a cardset option, or even an option that could vary per mechanic defined on the mechanics page.
However, I don't think I'd want to make it the default for all cardsets. How wordy a card looks with reminder text is a relevant consideration, especially when designing commons. (Of course, there's something to be said for gauging how wordy a card looks without reminder text too.)
keyword becomes an underlined link that when mouse hovered over pops up the reminder text. don't show reminder text because it clutters the card.
put this in a couple of weeks ago
I think this is pretty much covered by the recent search enhancements, particular card search "Restrict by user", as I described on Order by submitter.
What? Yes it is! Just use the Search page's "Restrict by user" and "Restrict by cardset" features that I rolled out two weeks ago.
Still not a thing :(
Still not a thing :(
Still not a thing :(
It works... except except or the lack of header and footer. I think it should be made much more explicit that skeleton generation does not "paste over" the older one (unlike editing the other pages or cards).
Speaking of which, I've noticed that "custom" card codes will cause the skeleton page to fail. It looks as if codes with a second letter not associated with a color will cause the entire skeleton table line to fail to render and no link will be created (in my case, I wanted MN to indicate undecided between colored and colorless). This would certainly pop up for anyone trying to introduce a new color. Couldn't those default to a transparent background?
I always intended for skeleton generation to be able to be an incremental thing. (That's why the line in the history says "generated part of a skeleton".) I'd have thought that by deleting the whole details page you ought to be able to create a new one from scratch; does that not work? (Or equivalently changing its title to something other than the magic name "Skeleton".)
But you're right, I should make it that if the existing page doesn't have a header or footer, it'll regenerate those for you.
Mmm, true. I always intended that people would just edit the skeleton after using the Generate page to create a template to start with, but yeah, that'd make some sense. You would have to specify what single letter you want to appear in the code for such cards, though.
A custom-line option that can be used for stuff that falls outside the normal realm (e.g. colorless nonartifcats, DFCs, split cards...) would be useful in general.
The most resilient I can see is:
When type becomes planeswalker:
If you're not willing to add a third field; then blanking the one you didn't pick is the second best option, I think.
Another equally less-good option would be to present a thid box for loyalty; label it as such, and flip to the planeswalker frame if the use puts something there.
Type is usually the last field I fill out. I'm not making a planes-walker; I'm making a card. Sometimes it turns out to be a planes-walker.
...Oh. Okay, I guess I hadn't considered someone designing a planeswalker typing a detail like initial loyalty before setting the big-picture things like type="Planeswalker". I would have thought the way it looks like a P/T box rather than a loyalty shield would dissuade you from doing that. But yes, what you propose is a plausible means for occasional users to submit planeswalker cards with nonblank power.
If someone submits a planeswalker with power as well as toughness (that isn't Jeska, Mending Medium), do you think I should actually ignore and blank the power, since I have no way to display it anyway?
it's exactly as Vitenka stated. it's easily replicated. make a new card, type in a value for power, then type in Planeswalker, then preview. you can see power value, no slash or toughness. at this point, the edit frame only shows one box for loyalty. so type in a value, then preview. now you see P/T. now delete the loyalty, then preview. you see just power value. so by this point, the user is confused since he doesn't know what happens behind the scenes nor what to do to get the loyalty to show up correctly.
I think the point is that a "new card" form comes up with two blank boxes, down in the bottom right.
It's not at all obvious which one you should fill in, if you want to make a planeswalker. Nor is there any prompting that you should fill out the type first, to make the frame change.
So people are as likely to pick one as the other. (Obviously, if someone is actually making a creature, having two is right and it's obvious what they're for)
Do I gather from the tone of your comment that you think you do understand why the bug appears? Could you have a go at explaining precisely under what circumstances a planeswalker can acquire a nonblank power?
i think you still don't completely understand why the bug appears, how the user interacts with the unintuitive interface, and why sharing fields in a database is a bad idea. as vitenka brought up, now you have to remember these exceptions for every type of output that could ge generated.