The stats box shows there are 25 MUDs listed here, but the list is only showing 19 of them… Where are the rest of them, is there a second page? Our is not on the main page… :(
24 Aug, 2006, Hades_Kane wrote in the 2nd comment:
Votes: 0
It looks like the main list page shows only the 20 most recent additions, or the 20 with the least amount of clicks. Mine isn't on there either, but if I navigate through Diku->Merc->Rom then it's listed.
yeah but if someone is just looking over the list to find one to play, shouldn't they all be listed, maybe with a link for page 2 ect… so that they have a fair chance to see/play them all and not just one ones that no one clicks on?
Hades hit the nail on the head ;) Only the top 20 with the least connections are viewed on the main page. But, if you want to see them all, go to the search option and leave the field blank and just search. It'll bring up every MUD listed.
Quick question about the Show All Listings link though out of curiousity sake.. What's the sort order for the listings when showing all? It appears to be sorted by date first, but then I can't begin to guess what the second sort field is.. though if it's by something funky like "if admin name = Conner list first", then it's perfectly okay to not disclose that and just leave it as is… :wink:
How about putting something on the manage list to show whether or not your mud has approved or still waiting? Just a little star or something for unapproved status maybe…
One thing, I listed Ansalon as Rom (as that's what it was in 96 when we started), but it showed up as TPmud when I just saw it. So I did the 'manage mud' button, changed it to Rom again… and now it's waiting approval again?
Maybe the manage mud button could do changes not a re-submittal?
I had asked about this elsewhere and was told that the listing isn't really being removed and resubmitted, but rather that when you edit a listing it becomes invisible until it's reapproved to ensure that nothing has been snuck in. Though I still think it'd be nice if, while the new submission was awaiting approval, the previous submission could remain in place.
As you pointed out Conner, the existing listing isn't removed. So it would be impossible to continue showing it since the contents of it have been modified. Which is why they don't show up until it's reapproved.
However. It's most likely possible we could handle the edits in such a way that the fields which would require re-approval are checked against the existing data via the POST variables. If the contents match, then the approval would be automatic. Otherwise it gets resubmitted as usual. This would allow for things like moving the codebase, changing the addresses and ports etc while still keeping control over the other fields.
If you look at my abio snippet, I chose to handle a similiar situation with bio authorization on my mud by establishing the chages to a bio to be in a secondary field and then once that new bio was approved, I replace the original bio with the new one. Couldn't you do something like that here the same way by having the unapproved edits in a temporary unlisted 'listing' and once approved have it overwrite the existing listing?
I'd rather avoid significantly modifying the database structure for what would be a temporary text field. I think it would be sufficient to allow the simple edits to go through immediately. Waiting on re-approval for the big ones isn't that bad.
No, it's not that bad at all, Samson, especially if the most common edits would auto-approve. Though, I know for my own mud, the most common edits would be changes to the description since it seems fairly unlikely that our code will be relocating given that I self-host, and so on but we're always adding new features/areas/etc.. and possibly the banner should we ever find a better one to use. In any event, we voted you in-charge of this project, so I'll take whatever I can get and be content that I got the concessions that I did. :wink:
Ok, separate issue, Samson, could the header for the mudlistings display how many mud listings are within their tree instead of how many branches are within their tree?
Ok, separate issue, Samson, could the header for the mudlistings display how many mud listings are within their tree instead of how many branches are within their tree?
That one is already on the table. Just waiting on Davion to prod the system into returning the right counts :)
Ok, separate issue, Samson, could the header for the mudlistings display how many mud listings are within their tree instead of how many branches are within their tree?
That one is already on the table. Just waiting on Davion to prod the system into returning the right counts :)