Looking for game search suggestions. You post a meaningful suggestion, and at the end of the month I will random off a copy of Secrets of Faydwer. Make sure you post your suggestion in this thread as other threads will not be in on the random.

This includes all the game database pages like game search, items, spells, recipes, mobs, maps, etc.

EDIT: I'll only be shipping this to the continental US unless you want to pay for the shipping yourself.

I've got one (or two)!

Right now on the item search results page, I can only sort results in ascending order.

Make the column headers alternate sorting every time they're clicked: if I click the STR column header, the results will be sorted by their STR attribute in ascending order; if I click STR again, they're sorted by STR in descending order; click again, ascending order; blahblahblah.

Add sort columns for recommended and required level, too!

Also, on the advanced item search page, it would be nice to be able to filter items by a couple more criteria:
-filtering to show only quest rewards (possible?)
-filter (or sort!) items by the zone they're found in

Thanks for taking suggestions!

Any way to show if an item is related to a specific quest?

I agree that the multi directional sort is a must. The quests are problematic due to the randomness of quest scripts. A bit of software handled it in the alla clone but it was... Unreliable we'll say. I think it could be done but it realistically would need some database structure to it. Then a text larding script with some serious logic behind it, some sort of manual intervention when it gets confused, maybe or maybe not some perl execution too. It's hard to say how reliable the result from it would be, but it is possible.

As an example to the chaotic nature of the quests, rewards and text may vary on race, the $race variable. There would have to be an option in the DB about this. The other issue is what if a script has something odd in it like it saves $race as $myrace. The script wouldn't know what to do with it. Short answer, doable with questionable results.

I've been very torn in the past on doing something with that because I really like the reliability of the data here, that's what puts us above allakhazam and the like in my opinion. Perhaps it's worth the risk of innacuacies though.

So to find out if an item is part of a quest you would have to parse quests scripts? I can see that being a real pain. I don't know how the db is set up so I'll assume there is no entry on items that links to quests? The quests themselves do an item id check or something?

Even if we didn't see rewards it would be nice to know where the quests starts. I guess we can just manually look up items on alla but that would only be accurate if the quest is identical to the current state on live.

This is the only thing I think is missing from your setup. I think you have tons of great info in there, just no quest info. One tiny thing I guess you could add is when you are looking at zone page and click dropped items link it jumps down to an anchor at the item table. The first time I used it and clicked any of the links I thought it was broken until I scrolled down. :)

I don't want to be in on the SoF contest, since I already have it, but I have a suggestion;

The main thing that keeps me from adding an alla clone or something similar to my server is that it opens up the entire database for searching. Which means that as soon as we make new custom content, players will already know exactly what to kill to get item X. If there was a way to block content by zone or whatever, it would certainly make me consider adding a feature like this. That way, new zones could be blocked from being searchable until all of the content in that zone has been done at least once. After a zone has been opened a while, the block would just be removed and people can then search it like any other.

Blocking searches like that might be a bit harder than it sounds, though. The easiest thing to block is searching for NPCs/Drops by zone. But, if someone spent a bit of time searching by NPC stats or item stats, they could probably find a good deal of new content information that they shouldn't yet have. I don't know an easy way around this unless each search also checked where the item/npc drops/spawns before displaying items. So, it would only display NPCs and Items from zones that are not blocked. Unfortunately, that would still leave quest items from new content as search-able, but that is at least limiting the issues I have with a tool like this considerably.

I find it interesting that you brought that up trev. I had been thinking about that with trying to setup this custom server. My theory on the matter was a mirrored database. Then on items, mobs, spells, etc, add a "discovered" field. I don't know that this would have any impact on any of the queries the server does, but my anticipation is that it would be pretty safe. I do believe cave has added extra little tags here and there for things. This might even be something we could request of him. From there we inject little snippets of code into certain server functions. For instance, there is an item generation fuction or something like that. We have it check this "discovered" field. If it doesnt exist, then we add a player name and or date to maybe a 2nd field. If it does exist, then we just skip it.

Then the alla clone would have to be modified to view said fields and only display the items listed.

Greenbean... the way the quests work is there is a file system with a folder named after each zone. In that folder are text files named after the NPC. It will be a perl script with a few specifically named functions in it. For instance something like(forgive my syntax, its WAAAAY off, I always have to cut n' paste when writing cause I'm not super familiar with perl)

More +

EVENT_ITEM {
  if ($item == 4172) {
    give(7894);
    say("you found my lucky rabits foot!);
    exp(5000);
  }
  else {
    returnitems();
    say("What is that? I don't need that");
}

So anytime you hand an item to any NPC, it looks up that zone, and that npc name in the file structure. If it exists, it opens that file as a perl script, and runs the EVENT_ITEM code, it'll pass a bunch of variables like $item, $name, $race, $class... stuff like that.

The things like say(); exp(); and others call prebuilt portions of code that will perform that certain task. There was an existing script out there that subsitutes the code for say() with a chunk of code that would enter it into a database. The problem is those limitations I mentioned before. So... "give()" could call a chunk of code that would enter that item into the database as a quest reward. The problem is mostly with items that you give to the NPC. For those the file just flat out HAS to be text parsed to find out what items are valid turn-ins.

I think it could be done, and its a really good idea... its just problematic =P

Yeah, I just like to avoid changing the database unless there is absolutely no other way. Adding the ability to block npcs/drops/items on a per-zone basis should resolve almost every issue I have with this. That is the main thing. That might make considerably more queries to generate a list, though. It would need to check spawn2 info, loot info, etc to find the zone each NPC is on and the loot table on each NPC there.

For dealing with blocking particular NPCs or Items, you could make a single table just for your tool. It could be as simple as having 1 column for EntryID, 1 for NPCID and 1 for ItemID, and then last would be an optional Notes column for the entry. Then, you just paste NPCID or ItemID in each row you want to block and remove them from the table when you no longer need them blocked.

Doing stuff in the existing items table or npc_types or whatever would just be hard to manage, IMO. Tools are best when they require as low maintenance as possible. I might have to think about this to see if I can come up with any other possible solutions for it. Really, I think just blocking items/npcs by zone would be good enough for me.

I would love to see an era filter on the search, like on premium alla.

I.e. You can select mulitple era's to search in. Classic/kunark/luclin/POP etc.

At present, when you search for a particular slot item, you get all expansions.

Great work btw :D

Been using the site for a few weeks now, pretty impressed with it! But here are a few suggestions/fix requests of mine:

1) Proc Mod on items for example: http://mqemulator.net/item.php?id=28855 I think it has a 55 proc modifier off the top of my head, would be nice to show on the item page.

2) Tribute of item.

3) HP Regen doesnt seem to be showing eg http://mqemulator.net/item.php?id=8364

4) Resist Adjust on spells as well as under the NPC Spells Cast list (would be extremely useful!)

5) On spawn timers, would be really useful to add the variance as well. And perhaps if hours greater than 24 hrs, it could say days and hours rather than the amount of hours?

Not sure if these were the sort of suggestions you had in mind but there you go :)

Scotty... you nailed it =)

1) brilliant, I always viewed that in game with the MQ mod that adds it, but it never dawned on me that it didn't show up on here.

2) I'll have to do some learning on that one, I never used the tribute system

3) That one looks like a bug, that'll go on the fix list too.

4) good idea

5) also a great idea, I didn't realize spawn time wasn't broken down into days. I can either add variance as another column, or do something like change the current spawn time into a range.


Ranjer,
I think that is doable, but it will be a large undertaking. I think I could add an era column to the zone table, then when items are queried it could do a custom query when era is selected. This would link the zone to the NPC in that zone, to the items they drop. It gets a little fishy though because there would have to be alternate links in the database query for ground spawn, fished items, tradeskilled items, store bought items, etc. If a decent quest system isn't formulated as someone else suggested it would make this theoretical query not be capeable of returning quest items from an era.

The cleanest smoothest way possible, and the way i understand allakhazam has it set up is each individual item is flagged with the era it came from, but with the thousands and thousands of items in the DB this wouldnt be all that likely. I think some of our data comes from lucy, which is allakhazam owned, so maybe there is some field in the item table I missed that can handle this. I'll have to do some research.

Great idea though :)

Oh I forgot, it doesn't seem like Summon seems to be working on NPC Special Attack list as it's deselected for all mobs.

I should be paying you =)

If maxlevel is set other than 0 in the npc_types table, you could display the level range an NPC can spawn as. I don't think PEQ uses that feature yet, or at least not much if they do, but it is something to consider for your tool.

It also looks like you only display 1 version of an NPC from a zone if multiple have the same name. In the case with multiple having the same name, it would be nice to see level ranges for them as well.

Does your list of NPCs check for unique loot tables for each NPC as well as checking for duplicate names before creating the list of NPCs in a zone?

I didn't see coin drops listed yet, if you wanted to expand the NPC info a bit more.

I was thinking about it and if possible, it might be cool to add a server status page and/or plugin that people can use to link to your magelo tool. Something that shows if the server is online/offline and the total number of players online that could be put in HTML into a module for homepages or whatever. Then, have it so they could click the number of players online and it will show a list of all players in all zones currently online (maybe 50 per page?). And from there, it could have links for the character names to link to their magelo clone profile.

I was thinking of working on a really simple version of something like this for my website, but thought you might want to add a feature like that right into your tool. It would be a nice easy way for people to check profiles of people they see online. :)