Superkalle

Amazing review! Very thorough with lots of details

Odd that both of you get the same problem. I recall Lychir having a problem too with the MAC version, but not sure it was related. Can you start LDD in Safe Mode (Compatibility Level set max to the right), and then try to save. Also try "Save As" LXFML. Just to see if you can get the file saved so it can be examined.

Thanks for asking, but not really unfortunately. The table of right/left versions is the easier part. It's the algorithms that is the hard part (for me at least).

Hi DawnTreader As for the first question, I'm kind of bogged down with work all kinds of activities and work at the moment. I'll do my best to get an update out. As for the second question, I did make a first attempt at such feature last year, but it turned out to be tricky. The thing is that the LXF-files only contain the brick center-point position and rotation matrix, i.e. not the geometries themselves, so to know how to mirror a model, one needs to know the center point and symmetry line(s) of the individual bricks. Besides that, you also need a lookup table for all bricks that exist in a left/right version. Nothing not doable, but it was just a bit too much for me

After some analysis, I found there seems to be a collision error in the inner "corner", circled in blue in the attached image. The black beams cannot be pushed any further in towards the middle. I'll report the error and let's hope it gets fixed for the next brick update.

Yes, it's a good idea. I will think about it. Perhaps with small pictures to show brick and color for easy recognition. And with a checkbox so you can tick-off that you picked the bricks?

Well, in that case, you need to first import the 5891 LXF-file into LDD Manager, and then use the function to generate an LXF from it from the "Spread out parts" feature (in the Import dialogue). That should give you the stacked brick version. An other solution would be to use the File > Export BOM in LDD and then extract the three columns Part, ColorCode and Quantity and copy&paste them into the GenerateLXF-function in LDD Manager. A third method to get the stacked version is to copy&paste the Bill of Material from BrickLink. The instructions for this are all in the LDD manager help file. This last method for example is necessary if noone has made a LXF-file of a set. I noticed however when I download the 5891 now that the version from "ashir" doesn't work. And the other one from "Johnnhiszippy3" needed to be open in LDD and then re-saved since one brick is no longer in LDD (86209 has been replaced by 60601). Anyway, I helped you this time, so please find attached two files 5891_-_apple_tree_house2.lxf 5891_-_apple_tree_house2_stacked.lxf

Hi ruccolo No, the Access-file is protected, so I'm afraid you can't make a report. What kind of report where you thinking though? Maybe I can make it? @bricksan: I just noticed/saw your post now. Sorry I missed it before. I'm afraid I don't have any good answer to your question. The general tip I suppose is to remove the current version of LDDManger, download a new fresh copy, and put in a folder you know you have full access to (read/write).

The stacked window is only something generated by LDD Manager as a means to visualize the bricks in a LXF. It is not a feature of LDD. If you read the manual of LDD Manager, it should tell you how to create such generated and stacked LXF.

Hi and welcome to the forum! I'm moving this to the Town forum, where hopefully you'll get even more help.

A new issue of the excellent Hispabrick Magazine is hot off the presses. Click here to download, and click here to discuss or comment

Yupp, there seems to be a collision error in 6152. Tip: Make sure to put in all parts in the LXF, and just place them on the side if they don't fit. Then at least the part is in the file.

In the link that Gnac posted, it says a few rows down (in Step 2): "NOTE: If you use an existent LXF-file, then skip to Step 4.". This means that you don't need to use LDD Manager if you already have a LXF/LDD file. Instead you can just put in the designated folder.

As mentioned before, LDD uses the same master data (part database) that the rest of TLG. To keep a separate database or register maintained for LDD alone, where one could introduce these special DesignIDs (A, B etc), is not feasible. So the only solution within this framework is to use (if they exist) transparent mold counterparts. I agree it's not the ideal solution, but it's either that or nothing unfortunately. At least that's how I understood it. Also, this solution/workaround will only be possible for those few cases where there is a specific DesignID for a transparent counterpart (Polycarbonate). As for now there is only two relevant cases that I know of - the antenna and the 1x2 wall element that Blip brought up a few days ago.

OK, then I understand you. All OK

Well spotted. I hadn't seen that bug before.

It's not really that anyone is failing. It's more that they add alternative DesignID's on a "need" basis, so that's why we users need to point out the issues when we see them (which was done now with the 1x2 wall element). LEGO internally have no use or need for these alterantive ID's as they only work with and use production bricks.

I managed to fix this. see attached file (also fixed the color of the yellow wings (which was supposed to be tan, see here ) You can take my fixed file and update your post if you want. 8370-8371_twin_powered_buggy_fix2.lxf

The main purpose of that topic was in the beginning to index LDD MOCs spotted in the other sections of the EB forums. This was perhaps most interesting in the early days when LDD was still kind of new and we wanted to showcase inspirational models to each other. Today I'm not sure it's needed in the same way as a specific index for just MOCs with LXF-files. And it's a lot of work to keep an index going

Which brick do you mean? I can't find 32031. If it's 32034 you mean, it has connectivity on the two "side" holes. This typically happens when TLG re-uses the same DesignID to replace an older style brick with a new one. It's normally done on the basis of "equability", i.e. that the new and old style has the same function. It is quite common practice in general industry in order to conserve part number usage, and to avoid having to update spare part catalogs etc. However, TLG does have an issue of inconsistency here, because sometimes they pick out a new DesignID for a very similar part, and sometimes they don't. Also, because bricks normally survive for years (sometimes generations), they should have a more strict policy to always pick out a new DesignID when there is a change in both function and form. Now, as for LDD, my understanding is that the guys in the LDD Team are caught in between, because they know and realize that there are a lot of people out there that want to use the two different shapes (square vs round corners). So they try to help us fans by fixing so that we can have access to both the old and the new shapes without breaking the "rules" and introducing fake DesignID's. One example is the 3957 vs. 30064, where the latter was the old DesignID for the transparent version of the brick that could then be used. BrickLink, Ldraw etc normally get around the whole problem by adding a, b, c etc after the brickID's.

(split into separate new topic. The other one was 3 years old).

(Created separate topic of this)

I'm not sure this will help with what you're talking about, but baseplates in any model really slows LDD down, and makes it harder to place items too (IMHO). I usually hide them while building stuff. PS: Just looked at the build now after Otakus turn. Looks great! For what it's worth, I straightened the model (couldn't help myself ) eb-rcb5-turn15_straightened.lxf

How do you mean it hasn't been fixed? I find two ways to fit it. Or did I miss something.

I'm closing this topic. Please use topic mentioned in the link two posts up