djm

Members
  • Content Count

    9
  • Joined

  • Last visited

  1. Hi Simon, I've posted a question in the LDraw forum regarding images for official parts. I'm away for the Easter break, so I won't have a chance to have a look at the lists you created until some time next week. Regards, David
  2. Hi Simon, thanks for that. If possible, a simple text file with one part per line for the two files (missing_ldraw.lst and not_used_ldraw.lst). Perhaps pop them onto BrickSafe and send me a message with the link? There's an aversion to defining the corresponding BrickLink number within an LDraw file. If this approach is used, it means that a renumbering of the part within BrickLink would require the LDraw part file be amended and then resubmitted for approval. I'm currently scratching the itch to see if there is a way to define the relationship between the LDraw part number and other systems (Rebrickable!, BrickLink, LEGO, ...) with a separate automatically generated mapping file. David
  3. Thanks Simon, that tells me that I will need to do some kind of comparison to the LDraw part ids to confirm whether or not the LDraw part actually exists. Off I go to the LDraw forum. Regards, David
  4. Hi Simon, this is the link to the LDraw forum thread. The script I wrote uses the Rebrickable API, so we can see/process the list of external ids but do not know which is the "best" (very subjective term) one when there are multiple ids. The rule of thumb might be that when there are multiple part ids, we could take the first one in the list. That should at least result in predictable behaviour. The discussion is at a relatively early stage but the premise is that it would be run periodically although with a reasonable gap (e.g. monthly?) between runs. You would be welcome to contribute to the conversation. Regards, David
  5. A question related to the same work identified in this post. I'm looking at the Rebrickable external ids for LDraw parts. I was wonder the following; If a given Rebrickable part does not explicitly list an different external id for its equivalent LDraw part, does this always imply that the LDraw part id is the same as the Rebrickable part id? Are there any Rebrickable parts which do not actually have a corresponding LDraw part (for example, this)? If so, is there anything in the API result for the part which means there is no LDraw part (as opposed to it having the same part id, and hence not listed in the external ids)? Regards, David
  6. Hi, over at the LDraw forums, there is a discussion going on about using the Rebrickable API to create a cross-system part mapping reference file. I've knocked a script together which queries the Rebrickable API for the parts and then renders it as an XML file partially akin to LEGO's LDD ldraw.xml file. One of the questions that has come up as a result of processing the data is with regard to a single Rebrickable part being mapped to multiple part ids in an external system (e.g. LDraw, BrickLink, ...), such as seen here. The question is can any meaning be placed on the order in which the external part ids are listed? For example, is the first part which is listed always going to be a more recently generated part, or is the order in which they are listed when there are multiple part ids random? Regards, David
  7. The LEGO Database Download files at https://rebrickable.com/downloads/ are all 0 bytes. David.
  8. I've got a MOC (http://rebrickable.com/mocs/djm/akiyukis-zigzag-stairs-gbc) which was defined with a single quote in the name. When the MOC details are updated, the single quote is being expanded (by one single quote?) each time an update is made. I'm using Chrome (49.0.2623.112 m) on Windows Vista. Regards, David