seejay got a reaction from KristofPucejdl in Anyone have success selling MOCs?
Thanks Kristof and Gumalca. Those are all useful comments. I agree with you about giving away small models. Only a couple of mine were premium until recently, but I thought I'd see what happens if I take the ones that were getting downloads and put a eur1 price tag on them. As expected, no more downloads. The Marble Maze has sold once and I think that traffic came from tweeting about it at JKBrickworks (who designed the original maze set on which it is based). I also shared it on Eurobricks and Reddit. I can see in the MOC analytics that all those things helped, and to some degree the increase in traffic seems to be holding, which is nice.
seejay reacted to sirjective1 in Allow subtraction of parts from a list via the parts search interface
I did something very similar over the last few days: I already knew a bit about Node.js, so to learn more about it, I learned the RB API good enough to use it for moving parts. 🙂 My hacked-together script now takes a CSV file containing the desired state of a part list (e.g. exported from a custom list made from a MOC), the "target list" to be filled with the desired parts, and the lists to take the parts out of ("donor lists"), and then moves the available parts from "donor" lists to the target list using the API. It was a really good learning experience. 🙂
seejay got a reaction from jaredhinton in 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 . . . :)
seejay got a reaction from jaredhinton in A part listed in my "parts missing images" page has an image
Thanks Jared. That's useful to know. I was planning to break out the light box and take some photos as I've done in the past.
But I've also been recently submitting change requests to improve the generic descriptions on some printed minifig parts, and those were taken largely from BL (and noted as such in the change request). So your comments here are helpful. You may want to consider adding some text about that to the change request dialog.
seejay reacted to Simon in Set 10152
Thea has done the research for this, so this particular case is hers to decide. I am not going to interfere with that, but I do have a general observation.
There are probably two dozen LEGO colors that we don't recognize as separate colors, and which are currently mapped to an existing Rebrickable color. If you look at our color table, all the double entries in the LEGO column represent at least one LEGO color we don't recognize as separate color. As an example, both LEGO colors 316 Titanium Metallic and 148 Metallic Dark Grey are mapped to Rebrickable color 148 Pearl Dark Gray.
Some of these LEGO colors are virtual, they were introduced in earlier versions of LDD, and removed again in LDD 4 (probably never used in real parts); some are only used for a single occasion (Metallic Red for a single minifig); but LEGO is increasing their color pallete again (consider the Sprayed Gold for the new Lunar Model Creator Expert), and if they re-use color IDs that are currently mapped to another Rebrickable color, we will be forced to split colors, like we did with Pastel Blue.
Obviously we can change the color of some parts in set inventories, and the resulting build problems with an owned set can be easily corrected by removing the set from your set list, and then adding it again with the newly changed inventory. However, we can never change colors in user's part lists.
So this basically reverts to the same discussion we had about the impact of inventory changes. Yes, if we correct an error in an inventory, your part collection may change. The same applies for color corrections. But arguing that we should stop correcting errors because it might impact part collections is both unattainable and discriminatory against new users, with small part collections.
Our users expect our data to be as accurate as possible, and rightly so, and many of you are actively helping us to correct any errors, for which we are very grateful. Sometimes these correcting can have a bigger impact then expected, and if we can, we will try to help you solve those problems.
But please, do not ask us to revert a warranted correction on account of part collection continuity, because such a request is basically asking us to stop correcting errors, and we can't do that.
seejay reacted to jaredhinton in A part listed in my "parts missing images" page has an image
while I can’t help with your issue I would just like to take a second to reinforce a key policy. We cannot use information from BrickLink. So when the above gets fixed and you start submitting images the images must be taken and owned by you.
Please take care when copying descriptions and numbers too as we do things slightly differently to BrickLink (but that’s not photo related just for any new people reading this, haha)
seejay got a reaction from Ian-D in LEGO Database Download page - suggestions
I have an ugly little workflow that I knocked together in Python (mainly using Pandas), with Dropbox to move the result around, and Google Sheets to view it. It runs nightly from my local machine and pulls out all my parts list into a single CSV (with a column indicating which Rebrickable part list the part is from). It creates a date-stamped version of the CSV (for backup) and a "always the latest" version. The latter is synced to Dropbox and I have a Google Sheet that reads it live (using the IMPORTDATA function).
This workflow gives me a backup of my parts lists and and a quick way to search for parts in Google Sheets if I don't want to go through the Rebrickable interface. I find that I use both Rebrickable and the Google Sheet depending on what I'm doing. Also, as an intended benefit, I can go back through the date-stamped versions to see how my parts total has changed over time, which is probably about the nerdiest thing I've ever done for fun.
If that sounds like it might be helpful to you, send me a DM, and I can send you the script. You'd need to be comfortable in python to make any sense of it, but it sounds like you probably are.
seejay got a reaction from Ian-D in LEGO Database Download page - suggestions
Hi Ian. It's in python 3. I'll send it by DM.
For uploads into your parts lists, Rebrickable has great import functionality from almost any source you care to work with via the interface. For my initial inventory (for which I spent a long time counting a lot of parts), I entered the inventory into a csv and imported that. There's nice error reporting in the interface to help catch mistakes. I've also imported directly from Bricklink and Brickowl orders using the Rebrickable interface. All of those work reliably for me, so I haven't felt the need to build anything for uploads (or even set up a local db beyond the CSVs the script generates), but of course everyone's workflow is a bit different. It's awesome that Rebrickable makes that flexibility possible via the API.
seejay got a reaction from Simon in [high] BUILD CALC - negative part count
I just saw a negative build %. It happened when I had marked a MOC as assembled, but also had the inventory of that MOC as a part list marked as not buildable. So for those parts that I only have enough of for the MOC, it's like they were being subtracted out of the build calculation twice. When I removed the MOC from my assembled list, I got an accurate build calculation.
Hope that helps track it down, @Simon
seejay reacted to Simon in Part 3002 being erroneously converted to 3002a
My apologies, I am the culprit -smile-
I am working on basic bricks, adding new part images and link lists, and I added and LDraw mapping for 3002a to get the system to display the LDraw image (as the top of 3002a looks exactly the same as the top of 3002 - the difference is with the bottom of the part); and I forgot to switch off the import/export translation. I switched that off now, so your import should now be OK again.
To be sure, we do have an import/export translation for 3002old (Bricklink) and 3002a (BrickOwl). So those still get translated to 3002. If that is still a problem for you, please let me know.