seejay

Members
  • Content Count

    33
  • Joined

  • Last visited

  • Days Won

    1

seejay last won the day on April 12

seejay had the most liked content!

About seejay

  • Rank
    Level 2 Stud

Recent Profile Visitors

191 profile views
  1. When I import the attached inventory, I get color errors which don't seem to be "real" errors. When I manually edit the colors, Rebrickable accepts them (i.e. the part/color combination must exist in an inventory on RB somewhere). I think the color IDs shown here are LDraw color IDs. 326 is Yellowish Green and 10001 is Glow in Dark White, and these are the two parts that get "unknown color" in the resulting inventory. But as I said, when I manually edit the colors, Rebrickable accepts them. color_chart.io
  2. On the MOC Analytics page (which is great, by the way; it's fun to check those numbers from time to time), the table which lists all MOCs with their views, downloads and likes has small up and down arrows to change the sorting of the rows, however for me, none of them result in an ascending or descending sort. The buttons do something: the sort order changes, and the order is consistent if I change back and forth using different buttons, but it's not ascending or descending (or alphabetical).
  3. Hi Hannah, I think there a couple of things to think about. If you just want to get rid of as much of it as quickly as possible and are less concerned about maximizing the value, something like ebay is your best option. However, even in that case, I think spending some time researching prices on Bricklink would help you know what prices to aim for. The secondary lego market is very active these days. Even if you took the average current price for each set on Bricklink and added it all together as a single price to sell all of it, I bet you'd find a buyer. If not, knock 5 or 10 percent off that price and for sure someone will snap it up. If you want to maximize the value and don't mind spending more time managing the inventory, packing, and shipping, you could set up a Bricklink (or BrickOwl) store and put everything you want to sell up there. You'd probably be selling them a few at a time. That involves building an inventory of the sets and keeping that inventory updated as you sell them off. In all cases, you'll need to distinguish between the different states (sealed box, built and rebagged, etc) in order to figure out the right price. This article talks about an average increase in the value of lego sets of 12% per year since 2000, so I hope you'll be pleasantly surprised by the value of what you have. Good luck! --cj
  4. Sirjective1, I agree with you. I'm using the new links on the "my parts" tab to effectively move parts from one list to another but it is error prone and requires some mental juggling as you note. That new feature is definitely an improvement (thanks Nathan!) over the workflow I described in the initial post of this thread, but still a bit awkward, and slow if working on a bunch of parts. My solution (for when I want to move more than a couple of parts) has been to enter my desired changes in a spreadsheet (list name, part number, color, and change in quantity for each change I want to make) and use a python script to make the changes via the RB API. Hacky, but it works, and basically does what you are suggesting with your CSV solution. I'd be happy to see something in the interface that makes these kinds of moves easier.
  5. Thanks Vokhev. That makes me feel better about my powers of observation. And it's a fairly tidy solution to the problem. And thanks to Nathan and team for implementing them. --cj
  6. I think you can close this suggestion. I'm not sure if the function was there when I made this ticket or not (most likely it was and I had just not seen it), but it is now possible to go from the "my parts" tab in the pop up dialog on a search result and click on the part count for a particular color. That re-opens the pop up for the specific color clicked and there is an "edit this part" tab available. It seems like one more click than absolutely necessary, but it lets me do the workflow described in the initial post above.
  7. seejay

    MOC Tags

    Jared, I feel your pain. I'm deep in the weeds of tag wrangling for our site (which has nothing to do with Lego). I've reviewed all the tags manually to map them to a smaller set of standard tags, a painstaking, iterative process (just when I think I've got some logic to guide how to map the tags, an edge-case comes along and blows up the whole thing). Next we're planning to lock down the tag vocabulary and add a "suggest a tag" feature to allow users to point out any gaps in the vocabulary. We're also working to have the system recommend tags to contributors based on the title and descriptions they enter. That will be based on a machine-learning model trained on our the standardized tags. Not sure how well that's going to work, but I'm hopeful that in a couple more months our tags will be a lot more useful. Everything we do is open source, so if we get something that seems like it might be useful for RB, I'll link to it here, and we blog about our work at the Centre for Humanitarian Data. So, if you get bored after cleaning up all those minifig part numbers . . . :) --cj
  8. That was it! Thanks Nathan.
  9. This is probably not specifically an issue with the RB API and more about something I don't understand in python requests, but I've researched the latter and tried a lot of different things, so I thought I'd ask here for help. I'm trying to use a python requests to generate a PUT request to update a part in a partslist (changing the quantity, all else remaining the same). Based on the curl command in the API docs, I've tried: url = 'https://rebrickable.com/api/v3/users/token_goes_here/partlists/part_list_id_goes_here/parts/3001/0' headers = {'Authorization': 'key key_goes_here', 'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json'} data = {'quantity':17} #I think the problem is here r = requests.put(url,headers=headers,data=data) This structure is working for other http requests (delete, get), but those don't have a the data element, so I think the problem is there. I've also tried a few variations on formulating the data element: data = {'quantity':'17'} data = '{"quantity":"17"}' data = '{"quantity":17}' #and in desperation data = 'quantity=17' No matter what I try, I get status code 400, bad request. What am I missing? Thanks in advance.
  10. Hi Nathan. The original bug I started this thread with is back. Perhaps you just had to revert something and are aware, if so please ignore. But as of today, I have 60 parts without images the list, where as a couple of days ago, it was 0. I checked a few of them and all them had photos. You can see the first few in the screen cap.
  11. Thanks Nathan. I've never used that button and had become so used to ignoring it that I simply didn't even think of it. Would it make sense to have that button be checked by default? It seems like if a user is searching for a part, whether or not it has been included in an inventory wouldn't matter most of the time. And perhaps add a little hover text explaining what "unused" means. I think when I first started using the site I thought maybe it was parts that weren't "real" (colors that had never been produced or something), so I just didn't use it and eventually stopped seeing it.
  12. These two minifig heads are identical prints, one with a hollow stud and one with blocked open stud. https://rebrickable.com/parts/3626bpr0760/minifig-head-imperial-pilot-face-mask-and-silver-goggles-print-blocked-open-stud/ https://rebrickable.com/parts/3626cpr0760/minifig-head-imperial-pilot-face-mask-and-silver-goggles-print-hollow-stud/ Only the first is returned by searching for "silver goggles" (+ minifig heads + black), even though both use this phrase in the part name. I assume this is because the second one has year = "0 to 0". Even searching with the specific part number "3626cpr0760" still returns only the entry for 3626bpr0760. I don't think this is an error in the database; the years when the "hollow stud" version were produced seems to be unknown (both of these parts have only ever been used in a single set). However it means the part is not findable using the current search interface. Even tweaking the search URL to specify min_year=0 and max_year=0 (or 0000 for that matter) doesn't return any parts. I'm not sure how many parts there are with ambiguous years, but it would be great to make them more searchable. Perhaps consider adding, in the parts search panel, an "any year" checkbox to disable the time slider filter? I've attached a mockup to show what I mean, but I'm sure you'll have better ideas how to handle it. Thanks again for all your hard work on a site that I use and appreciate a lot!
  13. That makes sense. Thanks for looking into it.
  14. Thanks Nathan. Now I seem to have the opposite problem: I've gone from having several dozen parts in my "parts missing photographs" list to having only 2! I'll attach a screen cap. Looking back at the screen cap from my original post, the second item is part 11203 in tan, which is still in my inventory and doesn't have a photo. Maybe something will reindex overnight? I'll check it again tomorrow. --cj
  15. Hi Nathan, I just checked again (this time from a different computer to avoid any cache issues), and it is still happening. Thanks for looking into it.