Calabar

I don't think perfection is required, but parts should work in LDD as original parts at least, to avoid problems for LDD users. If you are able to create good geometries, I think your contribution could be very precious anyway. Otherwise your good contribution will be wasted, and it would be a pity. Another idea is to maintain two packs, one with complete parts and one with parts that need to be completed, a sort of stable and beta packs. In this way an LDD user could choose to install the "stable" pack only or both, knowing the issues with the "beta" bricks. A contributor could then choose to introduce a new brick or complete a "beta" brick, allowing it to be added to the "stable" pack. @Stephan , your opinion?

@jester I think any contribution is precious. If you (or anyone else) are not able/have not time or interest to complete your bricks, your work could be completed by another user and then added to the database. Am I wrong or someone told that there is a software that, when ready, will allow to add these elements easily?

@Solid Brick Productions I moved your post here. If you mean to contribute to the LDD Official Sets topic, I welcome you! Please note that the topic have precise rules about how to add a contribution, so please read them carefully (and take a look at the regular posts of other contributors). About hosting your work (both image and lxf file) I suggest you to use a LEGO related ones such as brickshelf or bricksafe.

I agree with Equilibrium. Ok, I don't understand the necessary effort to create a good brick, but it is a good idea to don't allow bricks that lacks important things like collisions and outlines.

@Corellian Corvette The argument has already been discussed here (and following posts) PS: please stop crossposting, you placed the same question about Bluerender and Blueprint in three different topics, it is not allowed.

Grammar is surely good, but these data are not easily detectable at a glance (in fact I missed them at start! ). I mean it would be useful a sort of application sheet, a brief scheme reporting (schematically) these (and in case other) important data. Something like: OS compatibility: Windows, Linux Interface: executable console or GUI Availability: source code and binaries Programming Language: Pyton License: MIT License (free software) Notes: works on files downloaded from Bricklink as wanted links (no bricklink login inside the software required) ... I think it is more readable than a conversational.only presentation.

@Kaero I can understand that have a second page to update implies a bit of extra work, but I think that main informations at least should be reported here too. I don't mean you should report detailed informations, but a brief view is necessary. Info such as OS compatibility, availability of a binary and such are informations that probably change very rarely. Beside remember that many users have no familiarity with software development platforms and could be lost if they have to find and understand information from an external source. Only a little list with the main info is needed.

Templates available are not suitable for a direct use? That would save a lot of time.

@Kaero Thanks. It seems to me that some important informations are missing anyway. Is the software provided as binary or source only? In this last case ho to compile/execute it? What about compatibility? Windows only? Multiple OS? Platform independent? Dos it require Bricklink's internal authentication? And go on... Probably I could get the answer to some of these questions reading more carefully or looking at the project page, but I think that a presentation page should report clearly this kind of informations.

Maybe this one? Click and Click and Click. Same topic, different posts. The topic needs a deep revision, but unluckily no availability to do it.

Thanks for sharing your tool. If you edit the first post of this topic inserting some screenshots and a little guide (in brief, add a more "colourful" presentation of the software), I'll add it to the section index!

The first assertion don't imply the second one. In fact LDD doesn't contain all the bricks but a small subset, so it is possible to request a brick that is not available both in LDD and in stud.io. Besides as SylvainLS explained you there are two kind of availability in stud.io: "full" availability (a brick is available for use in the palette and it is fully working with the proper connections) and "partial" availability (geometries are available if you import the project from an external font, but the brick could lack connections and is not available in the palette). Therefore, it is likely that many requests involve bricks partially available asking to provide them in full availability. That said, I'm not 100% sure that stud.io doesn't miss some brick available in LDD, but SylvainLS is surely an affordable font as he manages a pair of tools that converts LDD parts in LDRAW parts, so he knows what he is talking about.

Supposedly not right. If the file is saved as .html probably you are downloading a web page and not a pyton script. Access the page and find there the link to download the script, the link provided above by M2m is not a direct link to the file but to the project page.

Great, that's the data I wanted to see (obviously the useful data is a list of parts). So it seems that 1996? 1997? is the year where parts count increased dramatically. So my proposal is to concentrate the efforts on bricks released before this year in order to complete this finite finite set. I didn't thought so many old parts are missing in LDD, are old variants included in the graphics? About Duplo parts, I think we could give them very low priority at the moment.

It seems the statistics are much more complete than I meant. Great Work SylvainLS. Usefulness statistic is really very useful to create a priority list of new parts to add. Is it possible to distinguish designs from variants? I mean... it would be great to have all the variants of 4081 available, but in many cases variants are so similar that have all of them could have low priority. The lack of a design instead could be much more problematic when building a set containing it. And what about a diagram like the first one but no cumulative? It is the one I think is more useful: a list of new design IDs by year compared with their availability in LDD.