[New] EMC Market Buy/Sell Portal - Suggestions/Bug Reports

New Features
- Upgraded the add/update listing feature to include usernames, support to add different items when comparing, and defaults. The system is also routed through a more efficient back-end with fewer queries generated.
- Added a lot of shops, including 406, 411, 625, 701, 707, 1080, 1237, 1287, 1507, 1944, 1956, 2000, 2012, 2013, 2024, 2027, 2131, 2200, 2228, 2358, 3120, 3851, 4266, 4335, 10225, 10498, 14356, 14396, 14577, 14654, 14825, 15015, and 19000.
- Added the empire shop. (This is separate because it is a special case and required some degree of engineering.)
- Lots more comparisons available. All types of stairs and slabs, buckets, wheat.
- The bulk adder and listing add/modify now accept usernames. Usernames are automatically populated with the residence owner, which is correct about 95% of the time.
- Added tulip category, leaves category, comparison between nether brick items and nether brick.
- Consolidated error messages and notifications on the item listing page.

Bug Fixes
- Fixed a bug with the auto reader which affected all accounts newer than 90 days. When requesting a page number larger than the end of the rupee history, the site returns the entries on page 1. Since the reader would continue until no entries were received or it encountered an entry older than 90 days, it would reach the end of their rupee history and continue to spin on page 1.
- Fixed an error with sending of registration mails. Registration mails should be sending reliably now.
- Fixed a problem with searching up potions. (Any items with : in them.)
- Removed hundreds of duplicate listings and fixed the database to prevent them in the future.
- Removed a number of shops that didn't exist anymore.
- Fixed a few errors with incorrect comparisons.
- Fixed a bug with the bulk adder when adding extra entries of items the Empire Shop sells.
- Fixed the bug where username would not show up by default when logged in using the auto-reader.

Tweaks
- Optimized auto-reader to be more efficient.
- Removed items have a slight pink background.

Back End
- Added constraints on database tables to firmly prevent future duplicate entries and allow for more efficient insert on duplicate update entries.
- Added new optimized code to add new listings which is a lot more efficient.
- Added utility to find item IDs really fast (to speed up future development).

Thanks to everyone who's been contributing to the shop data and adding new shops! I think almost all of SMP1 is on the site now, and much of the other servers.

Great stuff, thank you!!

This is an excellent tool. Thank you for making this relatively simple for people to get a general idea as to the market conditions around the Empire. It's also awesome as a way to keep an idea of what shops exist around a server!

As a (hopefully quick) suggestion: It would be helpful to have a link to the search results for the item also have, perhaps near the bottom, a link to "http://minecraft.gamepedia.com/index.php?search=<SEARCH_RESULTS_HERE>" so as to make it a bit quicker for all of those times when we need to look up something about the item from the MineCraftWiki.

And another thing to consider: People are easily swayed by rewards, so it might not be a bad idea to consider a small bonus for people using the auto-reader feature. Perhaps for each market transaction, people get one rupee, with the fine print saying that if you try and game the system your market account will be banned. Certainly a possible issue, so you might want to throw in some fail safes which I'm sure you can figure out/will end up figuring out (feel free to ask if you want some ideas for these). And while a single rupee per transaction might seem small to some, it's one more rupee than people would get, per transaction, otherwise.

As a "someday" feature, assuming the tool continues to grow in usage, it would be excellent to have "price watching" functionality for both buying and selling. Being able to set up a condition based upon a search result (either item or category), and a price to match or be less/be more depending on if you're setting a buying or selling price watch. Optionally a specific server, specific shop, specific person, and maybe even time frame would be excellent features to consider as well. It'd also give people even more reason to sign up for an account.

And as another "someday" feature, which would require collaboration with Empire, and a java programmer if your Java isn't up to snuff, but a mod for MineCraft that works directly through the interface to provide data on specific items. An NEI plugin might be the easiest way to go about this, but alternatively something relatively simple using a command line interface to return data on a specific search query could do the trick. It's not really required, but if this becomes popular enough then it'd surely be excellent to have, for sure.

Hopefully this tool will continue to grow and become an integral part of the Empire community! And, again: Thank you for this awesome website!

Love the addition of the accounts/bulk add/edit system!

Suggestions:
1. Ability to sort asc/desc by any column

2. Column that shows "last sold date/time" vs. last edited time (if that information is available)

3. Plus any other columns that show sale data, always useful.

4. Maybe a column/sort to sort by "type"? I don't know if this even makes sense given block IDs and so forth, if there ARE identified categories of items, etc, but I'm thinking something like sorting by category so you see all wood and wood-derivative blocks together, all plant blocks together, etc. Maybe that's not possible, so this is a stretch.

As always, many thanks for your work!

Who would supply those rupees? I would think that there are many many rupees to be made off arbitrage and having the extra information is definitely worth more than 1r/transaction. I don't have a huge issue getting people to use the auto reader. Many users supply their rupee history. I feel that the main barrier is the issue of having to supply passwords. I used to get information from staff, but there was a decree a few weeks ago that they can't use the site because it involves giving away their password. I have no control over that. I suspect a lot of users are very hesitant to supply passwords, and that any rupee bonus wouldn't change that.

One area I might consider rupee bonuses would be manually filling in shops. But 1r is very little and it wouldn't be worth it. And again the issue is where those rupees come from. One thing I was considering was a premium account level which you pay monthly to get quicker access to new entries. Normal regular users wouldn't see entries added by paid contributors in the last 2 weeks, for example.

I would like to see some examples of use cases for this situation, so I can understand the problem you're trying to solve and the real value.

Yes it would be cool if users could have a mod that reads shop signs as players travel around residences on the empire. That could be done with a considerable amount of coding. Obviously it would have to be approved by EMC staff. Someone could build this if they wanted and I would use/promote it. I'm pretty busy lately with the site and this would be something handy to delegate. I will provide an API for whoever the developer was so they could use that to upload the data. And it would be members only, to prevent abuse of the API.

Easier said than done. I definitely agree with this.

Currently, those two values are the same. A bump is an edit. Firstly, I would like to know how this feature/distinction would be useful. Secondly, there are some tough cases to sort out. A quick example = What should be the buy date of a newly inserted item? Would a bump still count as an edit? What value would show up on the search results? (There really isn't space for both.)

The data doesn't exist. How many items are sold during a 'bump'? The rupee history is a limited set of users, so the data would be very specific and there is a risk that individual user information would be revealed rather than aggregate. What are you trying to do with this information? Maybe there is a way to accomplish that same objective another way.

Type Wood, hit Wood (Category). Done. That will give planks and logs, sorted based on equivalent value. You can also do Wood Products, basically anything made of wood. If you just want logs, but don't care about the type, do 'Logs (Category)'. There are lots of categories you can search up this way. If you have ideas for others then let me know.

I don't have a plant category. One thing to remember is that items have to be comparable, so they can be value-sorted. In the case of plants, there is no way to value cactus compared to sugar cane, for example. In some cases I just gave a value of 1:1, like saplings, but the end result is you'll never be able to find a place to buy jungle or dark oak saplings that way, whereas the sell table would be dominated by those two.

Finding a way to make this market website profitable, such as stated below, would allow for you to obtain rupees to be used in paying for autoreader access. But if you aren't finding that getting people to want to use the autoreader is the hard part, but instead the issue is that they need to give out their EMC password, then it isn't much of a solution. It would still generate some more interest, but likely not enough to be worth it as such.

Perhaps the key would be (which you've surely done) trying to work more closely with EMC to allow for a non-password level of access to user's rupee history. In fact, that might not be a bad suggestion to make on here: Allow a person to set their rupee history to "followers", "members", or "everyone", and perhaps even whitelist specific users for rupee history access. This would allow ongoing checks of a person's rupee history without needing their credentials.

Failing that level of interaction between EMC and you, I cannot think of a good way to obtain rupee data without it requiring a modification (which will be discussed near the tail end of this post).

Premium access would surely be a good way to monetize this project, although I think that you might be going about it the wrong way. By restricting premium account level postings for two weeks (assuming I read what you said correctly) you would end up causing premium accounts a major downside as they'd have a much much smaller user base. Trying to get users to pay for an account just to gain access to better quality data will only be something, I'd think, you could truly consider doing when you have a large enough listing of premium data.

Instead, it might make sense to have something akin to a "sponsored" listing near the top which would have a slightly different coloring. While it'd be unlikely that the sponsored listing would be cheaper than the free listing, that wouldn't be an issue as the cost, quantity, and cost per quantity are listed. Users merely need to take the effort to read that data. The catch being that most users will likely just pick the first listing, and even if not, having a person's data displayed at the top would end up being publicity.

I would envision this working as follows: A premium account's listings are put into the pool of listings for each item (buying and selling) that they list. When that item is searched, that pool is randomly (or possible sequentially to give everyone a "fair" amount of time) sorted and the first listing is displayed at the top of the listings. I'm not sure how you'd want to handle a situation in which there are only sponsored listings, or a situation in which there are less than eight listings (seven being the most listings it seems will be displayed). In these cases, sponsored links might be better disregarded, but it might also still be useful to have them slightly differently colored to cause attention to focus on them.

And as an alternative to sponsored listings, it might make sense to "sell" advertising space. Instead of having their listing placed at the top of the listings, a banner is displayed near the top of the page whenever they sell or buy whatever is being searched.

There are certainly other ways to monetize this project for the sake of making it profitable to allow you a budget for paying people for their data, although my background is not e-commerce so I don't really have more than passing data on this area, sorry!

A real world example would be CamelCamelCamel. What that website does is it tracks the status of a specific item (or items) on Amazon, and when it sees a price that matches or beats your requested price it sends you a notification.

An EMC example would be as follows:

Guswut is in the process of trying to buy glass because he needs a new ceiling. He searches the EMC Market for glass but finds that the prices are too high. So as he isn't in a rush, he clicks on the "Looking for a cheaper price?" link which allows him to set a custom pricewatch value in rupees, quantity, server, and starting and ending date. He picks 0.35r per unit, at a quantity of five double chests (a built in calculator, or a way to enter quantities in "stacks" and "double chests" would be awesomely useful!), on SMP5. He doesn't fill in the starting or ending date because this purchase isn't time sensitive, so the values default to "now" and "n/a".

At some point, the glass economy drives down to being 0.35r per unit on SMP5. Guswut gets an email, or a PM via EMC's website (thus getting an email as well as the alert on the forums) that his pricewatch has been reached. In that email there are active links to "complete" the pricewatch (delete it, marking it as purchased, with an option right there of entering the purchasing details), "extend" the pricewatch (keep it, ignoring the value that triggered it and wait for a new value at a lower price), or "delete" the pricewatch (delete it, marking it as removed, with no option to add data).

This example also works in reverse, in that the person can be looking to sell an item, and use the system in the same way.

Now, in the above example, we actually came up with an extremely important and valuable piece of data: We can get theoretical future market data from the user base by asking them what they're looking to find. This might be useful data to allow people to search through (possibly at a premium, although it runs into the same issue with restricting data that other premium features have) as it allows people to get an idea what people want to pay for something. It might also even be useful to allow people to specifically target these pricewatches, although that is getting a bit ahead of the system and also a possible abuseable direction.

If I was better at Java I'd consider taking this project on, but my Java isn't even passable of recent. Hopefully you can find a programmer who is interested in this, as it would greatly add to your project!

If anyone is reading this, is a Java programmer, and wants to consider making a modification, you should seriously consider contacting azoundria to discuss this as it would certainly be an awesome partnership to start, and almost surely profitable for everyone involved.

I have been asking for such a system for long time. The largest issue is that Aikar believes it would be too hard to build, or wants to wait until the site is upgraded. I think they said they would build it when the site was bug free. I assume that will be some point after theft has been eliminated and all players on the server are happy.

Any user-created postings would be public. If a premium user is advertising their shop, for example, that would be public right away. If, on the other hand, I pay someone to go around and map out stores, that data would show up for premium users first. Premium users would get a 2 week period to pick off the good deals from the new shop (as there always are with any new mall). After the 2 weeks period the data would become public, however by that time the good deals from that shop/mall have most likely been sold out, filled up, or adjusted by the shop owner.

I think having advertising at the top is a good idea. I have an idea to let people bid on the top 3 spots for each item. The top 3 bids would have their ad displayed until someone else outbid them. (At which point they have the option to raise their bid.) It would take some engineering to build.

In the case of a site like CamelCamelCamel, they are dealing with actual products which are available with high probability. If something is listed on Amazon, I can buy it for almost certain. On the other hand, if something is listed in an EMC shop the probability of being able to buy it is low, especially if it is a good deal. As stock levels and even availability is completely unknown, it would be difficult to provide much useful information and a lot more likely to simply waste the user's time with repeated alerts about deals that are sold out or filled up (or were a typo to begin with).

A much better and simpler solution for your case where you want cheap glass for your roof is to set up a shop on your residence buying at the price you are prepared to pay, and add it as a listing so users can sell you glass. Not only do you not have to check any false alerts, you don't even have to go buy the glass.

Yes, come forward for sure. It would be a great opportunity to improve your coding and create something beneficial.

Bug free, theft eliminated, and everyone is happy... That sounds like a "never" to me, but I may just be jaded. I hope that is not the case!

After reviewing the thread in question, it appears that it is likely going to happen when the forum update goes through, which appears to be 2015-ish. That's excellent news, for sure!

Ah, that makes sense. In that case, yes, that would be an excellent "premium" feature, certainly. Although perhaps just having the buying/selling sales under the public market value stay hidden (different color, icon, etc) until they go above public market value (at the time they were set, because otherwise someone could report an extremely cheap sale, flood the premium values into the public, and remove the cheap sale as Gone).

Is there a specific reason you decided upon two weeks, such as market analysis on your end? Or is it just an off-the-cuff value? Just curious regarding that specific figure.

Yup, it'll certainly require a good deal of work to get that functional, although if you model it after the PPC (pay per click) model a great deal of the work in regards to the functionality is already completed. That still leaves the other mountainous molehill of programming it, of course.

Agreed, in the current model. But assuming that we get an API tie-in, you could be getting far more accurate and timely data without having to wait for people to use the autoreader, have people manually enter the data, or the like. In this case, the alerts would be useful assuming they were followed up with quickly. If you get an alert, but ignore it for a few hours, it makes sense that you are likely not going to find it applicable assuming the deal was good enough as such.

In regards to stock levels, the only data that could really be used to assume that would be quantity for sale. It's too bad that there isn't an API to deal with the storekeeping signs, and to allow all of this data to be parsed directly without needing these in-between methods. A much tighter tie in between the EMC and EMC Market would be required for that, of course. Likely not even worth considering, sadly.

That's a pretty excellent idea, and one to consider if I ever actually need something like that. Of course, it was just an example: My roof is going to be dirt and jack'o'lanterns until the day that I die!

That, and every so often checking the price of glass manually would be what I'd likely end up doing without a pricewatching feature. It certainly works.

That was my point it would likely be 'never'. But I can't say for sure. I will be ready when it happens.

Anyways, supplying rupee history through that auto reader takes 15 seconds of the user's time. If I was to have a bonus it would be based on per-time rather than per-transaction.

A months seems too long and a week too short to me. I didn't understand your example.

No it wouldn't be pay per click. You would simply bid on appearing. Once you have a leading bid, then you appear until you get outbidded. PPC would be impossible since there's no clicking typically and users are visiting shops. PPI (pay per impression) would be possible though I don't really see that advantage and that's more programming.

Yes there's a strong lack of data. Do remember that Aikar was trying to have the shop system work differently so you would simply buy items and it would buy the cheapest automatically, however that was considered 'ruining the economy' by many in the community. I'm also getting a few shops that don't like being sold out of their cheap goods yet refuse to raise the prices 'to help new players' so I guess the end result would be mixed.

Save the pumpkins, use torches?

I like your style, though of course one day the roof will be for a shop and sales rates are affected somewhat by how it appears. If it's just your house, well hope you don't get a girlfriend/boyfriend. Then again, maybe you'll be lucky enough to find a girl/guy who wants to sleep under the dirt and pumpkins with you.

Sorry, I easily confuse this tool with the EMC Shopkeeper which does, in fact, keep track of sales. I was hoping that that sale data was also available through the API that your tool uses, thus giving us the ability to see sales stats on items as much as inventory, etc. The idea here was to get data on "stale products" -- things people hadn't touched for ages and ages vs. hotter items. Perhaps a counter of how many times an item of mine shows up in someone's search would be useful? Just a simple increment. That'd give me an idea of what people look for actively at least, so I could further promote those items.

I meant for the category (and category sort) to show up on account.php, so we could sort our own listings by category. But if there's no easy way to have categories in some cases, then this won't always work.

Three New Suggestions:

1. The ability to add an email address to our profile so when someone clicks Out, Gone, etc. on an item in our store, we get an immediate email letting us know.

2. On account.php, a column showing the average price for the top 10 shops of the same item (similar to the search results) so we can see how our pricing compares to the average.

3. On account.php, make the item icon a link to a new search on that item.

All good ideas. Only a couple comments.

Here are the items people are searching for:
http://www.azoundria.com/emc/market/volume.php

Would you like a list of items grouped by daily search volume, and your corresponding rank in the buy/sell category for each item?

Which average should be used? For buying or for selling?

Ok, that's a great listing! Very, very helpful.

I was thinking more along the lines of any sales by myself in the above volume.php shown in a red paran-enclosed amount, so for instance, if I sold diamond and sold 3 on October 6th, you'd see:

October 6, 2014 | 19 (3)

Or something like that. Up to you how you enhance this, but I can take it from here. Just being able to predict sales trends and popularity is terribly useful.

[/quote]

For me, selling, as I have no buy chests. (Rather, where I am buying from the customer.) I try to run my prices near to the top 10 average so I always show up in the first page of results and this would give me a good, easy target to see if I'm far out of scope or not.

This is awesome. Thanks for taking the time to make this! It's definitely going to be useful for me
Only concern I have is the Empire shop prices being considered in the average price for an item: For example, a Nether Star, which has an approximate price of maybe 15-20k in player shops, is sold for 150,000r in the Empire shop. As there is little data on the Nether Star page, the average is brought up to a whopping 100,666.667r, which might lead to some confusion.

Sorry if someone has already mentioned this/you are aware of it, I think I read through most of the thread before posting but could have missed it.

That's true, and a good point; I'd keep Empire shop pricing out of any calculated averages, or at least show the skew, perhaps.

Just a thought, I agree both of you and I felt the same way at first but nowadays I feel Empire local shop is bit too cheap (I know it sounds weird lol cheaper is better all the time) and I think pricing can go up bit higher. This is from a shop owner's point of view. Sometimes I feel like my shop items are too cheap to sell if I think about time and effort to get those items by myself... I'm running a mini shop living in 1 rupee world.
So I think it's better for me to have Empire shop in average as a highest price point to raise up the average... a bit?
I know it's bit complex subject since I'm talking about decimals and the example is a nether star.

Well, I completely get what you're saying on this point! And you're right, if you think to the effort required to get some items and then what they sell for on the market, you're cutting a low margin. Of course I want the average to raise up when possible -- helps me out. But I don't know if that'll encourage people to globally raise pricing so we see more margin or if it'll just continue to be undercut by mass producers. It's something to ponder, for certain.

A mix of a suggestion/bug report with the caveat that the tab was old and so this may have already been addressed:

I just accidentally bumped a listing by reloading a tab that had been sitting in my browser for some days. It looks like this may have been suggested before, but if requests that change the database were always redirected away from to avoid reloads, I think that would be ideal. Using POST rather than GET is probably ideal for browser behavior reasons, but the redirect would be a good first start and I'd assume it'd only be a few lines of code.

Also, I'm interested in API access to EMC Market being provided.

I am one of those users that doesn't want to give up my password, but I'm more than comfortable writing/running code that I can review/audit or that may not need my password for one authority be given to another.

Also, rather than a mod for Minecraft itself, those that are notified about every sale could gather data from the Minecraft chat log. Such a program would not need to be written in Java, but should still preferably be written in an easily cross-platform language.

Anyway, an EMC Market API would be another way to improve EMC Market without necessarily providing a cross-authority password to your software or your needing to do all the coding.

I'm not sure how to do this without rewriting them all as forms, which would change the look of the page, and slow loading (though maybe the second doesn't matter to anyone anymore).

It's not in my control, and I don't think anyone is against the API. My understanding is that it's just such a low priority right now. It would be awesome to have, because it would turn occasional data from players who supply it into a steady stream of data that continues for each player forever unless they would cancel it.

That would be cool. Some players may keep their chat logs. I suspect a lot of players would not know how to do this and may find the process confusing.

You're suggesting I build an API. Can you give me an example of what data you would need and what you would do with it?

Maybe a framework is getting in the way? True for POST, you might have to use forms unless you used some client-side Javascript.

For the redirect, you'd header( ); exit; rather than outputting the page contents as you currently do, which is why I'm thinking that would be a relatively easy change. I think the redirect would probably be enough.

I was thinking of those comments as all part of one idea: you build an API. The password bit was just about part of why I'm suggesting an API. Sure, it'd be nice if EMC had an API, but I'm not surprised it's a low priority.

As for what I'd have in mind for the API you build for your site, it'd be pretty much everything that your site currently supports: querying buy/sell prices for known shops; adding/updating/removing buy/sell prices for the API user's shops. You might also support same for shops other than the API user's, but that could be abused pretty easily, so you'd probably want some sort of controls on that. The API you build might also provide statistical information such as item search volume and such, but in my mind, the first and core features would be querying/changing shop buy/sell data.