Calabar

@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.

The 4081 matter made me think one thing: it is possible that in LDD a part with variants such that one is stored with an incorrect ID? For example a 4081c could be stored as 4081 (a generic ID for that parts) because in TLG decided to use only the more recent 4081c to avoid parts duplicates because very similar. I remember there were some cases like this one. How to manage this situation if it should happened? @SylvainLS Sounds promising. I look forward to the result.

oh, right. I made a little confusion among BL ids and LDRAW IDs, considering them the same thing. Maybe we could obtain a better ID conversion using stud.io? I suppose it uses BL IDs, but starting from LDRAW IDs. Note that the only interesting IDs are design IDs, variants for colour or decorations have to be removed from the lists. PS: I usually use text tools too, especially RE, anyway in this case a basic query seemed to me the more suitable tool. Nothing to be worried for, the important thing is to achieve the goal.

Oh, ok, I understood that you removed the option to create the BI version! I thought something like using a checkbox "create BI file too" that create both files, but actually run the software twice do the trick!

Sure. the search have to be done using a coherent numbering. My idea was something like: get a list of parts released until a certain year (before TLG started to release huge amount of new parts), compare it with a list of parts available in LDD and obtain a list of parts that still need to be created to complete the list. A subtraction, in short. It should be easy programmatically (inserting data in a DBMS it would be super easy with a simple query), the problem is to produce the two lists!

Ok, tell me if I've understood. LDD maintain both group and BI hierarchies in the lxfml file in two separate areas. LDRAW instead maintain a single tree sharing both the informations (steps are included among submodel info). Unfortunately LDRAW structure has some limit (a part can't belong to a subgroup and to its parent group too), so it is not possible to maintain both the grups and the BI info from a lxfml file. What about to output two files? Something like modelname.ldr and modelname-BI.ldr?

Not a big problem, the statistic is useful to get an idea of the necessary work and if there is some little error it could be fixed once found building a set. Oh, well, I hoped it was possible to have a result with a single query

I was wondering... TLG produced a limited number of parts in the past and at some point number of parts increased dramatically. That means that with a "limited" number of parts it is possible to recreate ALL old sets. So some question: - is there a simple way to seem some statistics about new parts released year-by-year in order to see when the curve rises sharply? - it is possible to see how many of these parts are missing in LDD and which ones? All this why? For a sort of request: as old parts are limited in number, it is possible to concentrate the work to recreate all these parts, so that all old sets became fully buildable...

The problem with the LDD Official sets topic is that is supposed that everyone that possesses LDD is able to open the files. So we have to reflect on what's the best solution. About using githhub I think is a good idea. The main reason is that it is much more "persistent" than Dropbox: we lost many lxf files in the Official Topic that has been uploaded on Dropbox, while on githhub I can see projects discontinued many years ago. Persistence should be the first parameter when choosing the hosting site. Anyway GithHub is less intuitive when you have to download something, so I think it is necessary a little guide "for dummies".

Exactly! I've seen the addition in the New Parts topic, very good! You should add a date specifying the last update the image refers to. The image should be smaller (a thumbnail) and clicking on it should open the full size image (4k? ). The LXF could be provided with a text link. Some thoughts: Add a contributors list (name/number of parts) Add some rule about contributions: parts have to be completed, parts have to support all the necessary connections, parts have to came from an allowed source (for example LDRAW ok, Mecabricks no), etc... I suggest to distinguish new parts from fixed parts. It would be better to place the list of new parts in a new post (or more new post) following the first post. I have to clean the New Parts topic from unnecessary posts and move them here. maybe we can use 7zip format in its maximum compression to download the pack, if the size is huge? It should be better then both zip and rar. maybe someone want to create a new topic containing a simple&clear guide to introduce new willing contributors to join the process of creating and testing new parts? I should think about accepting new parts in the LDD official sets topic, at least as extra models. Or maybe I need to create a new topic! Stay tuned. EDIT: oh, I see the point has been raised already! Maybe Stephan we should add a private discussion!

I've seen the new topic created by Stephan, it seems very good. I suggest to add a clickable thumbnail of the new parts added similar to the one provided by Superkalle when a new version of LDD's brickset was out. Is there a way to do it quickly? He used his LDD Manager to create the lxfml file containing the parts, if I remember correctly, but I'm quite sure it don't work anymore. Maybe it is possible to create a simple script to accomplish this task. The topic could be the place where to post new parts code (maybe we could think about a common scheme, in order to facilitate the maintainer of the archive), but let's maintain this topic for discussions. I suggest to add a link to this topic in the first page, specify that every discussion have to be done here. I have to speak with the section staff in order to add a "key topic" tag to the thread.

So... any volunteer to maintain the LDD Expansion pack?

The work looks very interesting. I look forward for the public release of the complete animation feature. Many years ago I followed the youtube user tubafrog (now renamed Coby Basset) and his LEGO assembly animated video (example), Do you think an "assembly" mode could be added to the animation feature to obtain automatically a similar result? Excluding changes of camera position it seems quite prone to automation, bricks came from immediately outside at a stated speed and from the side where the brick is placed in the figure (mainly from the top as the assembly is usually bottom-up).

@SylvainLS Do you remember hrontos post about using LDD groups to creare building instructions? (I'm quite sure the references are still available in the Section Index) As you surely know, the lxfml file has separate sections for groups and instructions. Hrontos created a script to generate BI starting from LDD Groups, a very helpful tool that helped to make some sense to LDD instructions. Obviously, as the feature was not supported by LDD, the so built Building Instructions section in lxfml file was destroyed as son as the file was opened and saved again in LDD. How does your script works? Why preserving BI groups and submodels are removed?

It is possible to share these parts so that everyone could add it to LDD with a simple procedure? It would be very interesting to open an indexed topic with the new parts or, even better, a "pack" maintained by an expert user, it could give new life to LDD. @jester It seems that the image hosting you are using don't support hotlinks, it is necessary to copy the image url and paste it in the address bar in order to see the image. Maybe you could use a LEGO related file hosting such brickshelf or bricksafe.

Does it means we could expect ready-to-use lightmaps for all existing raised baseplates? The topic is becoming more and more interesting. Do you think to take methods 0-2 as example to refine your method or do you think to provide a multiple solution, wth the better one as default?

It seems that the washed colour fix had a side effect, the minifigure got older!