[KEY TOPIC] LDD 4 Bugs and brick errors

[Lyichir]

61801 seems to have a pretty severe boundary error. In the linked image part 33299 should not be able to phase into the other part that way.

[Toa_Of_Justice]

Has anyone noticed that part 2399 is missing studs?

[Zerobricks]

Nice find Toa... And its not just a visual bug, they are also not functional.

[JGW3000]

You can use part 50373 instead, it is almost identical and has the two extra studs on the top, in LDD. 2399 is no longer in production, anyway.

[Superkalle]

About 2399. Interesting! Has it always been like that?

I also noticed now that the tube on the underside is protruding further down then the side walls . And that the top studed 2x2 surface is out of system heightwise (if you put a plate on it).

[Blip]

Well, you are right JGW3000. From what I've understood, the reason it is like this is because LDD uses the internal Brick categorisation structure at TLG, which is used also internally by designers, manufacturing etc. And in that structure, only new/current bricks get moved to updated categories. Therefore old and new versions of the same brick can end up in different categories.

But I agree...it is annoying and takes away a bit of the use of the categoires in LDD, if you can't trust them fully.

Has the original 4865 panel 1 x 2 been moved to a different category in this way, or has some "clever" individual completely erased it in favour of the updated version with rounded edges? (It appears the latter, and if so I have a few words in mind for said individual... )

[mzoli]

I'm not sure if this has been reported before or not, but 32031 does not allow stud connection.

[Superkalle]

I'm not sure if this has been reported before or not, but 32031 does not allow stud connection.

Which brick do you mean? I can't find 32031.

If it's 32034 you mean, it has connectivity on the two "side" holes.

Has the original 4865 panel 1 x 2 been moved to a different category in this way, or has some "clever" individual completely erased it in favour of the updated version with rounded edges? (It appears the latter, and if so I have a few words in mind for said individual... )

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.

[mzoli]

Which brick do you mean? I can't find 32031.

If it's 32034 you mean, it has connectivity on the two "side" holes.

I'm sorry there is a typo, I mean 32013. It's needed for the rear lights in set 42031.

[Zerobricks]

I'm sorry there is a typo, I mean 32013. It's needed for the rear lights in set 42031.

Seems like a new bug... I could have sworn it worked fine before.

[Blip]

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.

And this approach is very much appreciated - but unfortunately makes it that much more vexing when someone on the team fails to adhere to that method!

[Superkalle]

And this approach is very much appreciated - but unfortunately makes it that much more vexing when someone on the team fails to adhere to that method!

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.

[telaruhn]

I noticed that in LDD, the Calamity Drone's hairpiece and hat won't connect. In fact, the hat doesn't work with most other holed hairpieces except for Red Harrington's (which I'm pretty sure the hat was designed specifically for). I don't know if it's how the geometry of the hairpiece and hat come together or if it's just a bug, but I haven't yet encountered this problem using other accessories.

[Superkalle]

I noticed that in LDD, the Calamity Drone's hairpiece and hat won't connect. In fact, the hat doesn't work with most other holed hairpieces except for Red Harrington's (which I'm pretty sure the hat was designed specifically for). I don't know if it's how the geometry of the hairpiece and hat come together or if it's just a bug, but I haven't yet encountered this problem using other accessories.

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

[Blip]

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.

If the process that the team normally adheres to is that they ensure both old and new variants can be accessed, as we've seen plenty of times before without having to specifically make a request, then it would seem this has not been done in this instance by whoever updated the wall piece. That to me represents a deviation from (and therefore failure to adhere to) the regular process.

Hopefully this one will get resolved soon in any case, since as you say it's now been raised. Thanks for your insight!

[Superkalle]

If the process that the team normally adheres to is that they ensure both old and new variants can be accessed, as we've seen plenty of times before without having to specifically make a request, then it would seem this has not been done in this instance by whoever updated the wall piece. That to me represents a deviation from (and therefore failure to adhere to) the regular process.

OK, then I understand you. All OK

[Calabar]

Why don't use a "variation" field to identify different molds for a single part?

Given that I think the best solution would be to give a different design id for different molds of the same brick, as this has not been made from the start and then it is not easy to apply now, the variation could be a simple and clear solution.

For example the part 3957 could be indexed as 3957 type A (the original) and 3957 type B (the new one). This approach is used by Bricklink also (and maybe other catalogues).

Use the DesignId for the transparent part seems to me a botch solution: it don't work for all the parts, it is not feasible if variations are more than one, it is substantially wrong, because that DesignID has a specific meaning for real parts but a different meaning in LDD (with all the trouble that this difference can create when you are trying to rebuilt an official set in LDD). The only advantage is that it makes possible to have a variation available.

Edited December 13, 2014 by Calabar

[Superkalle]

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.

[Lyichir]

LDD has been fairly buggy for me (on Mac) for a little while and I don't know why. At one point a part failed to load after I clicked on it in the menu, making it invisible—only when I placed it did it become visible again, and subsequently it turned invisible every time I tried repositioning it. Several times I've found that the arrow key indicators when moving a part disappear and are replaced by random glitchy graphics. Today I saved a model and then the whole model glitched out, looking like a hot extruded mess. I had to close the program and open it again to fix it, and thankfully the saved file was perfectly normal as if nothing had happened.

I don't know why these glitches are happening but they're really getting on my nerves (along with other unfixed bugs, such as the continued inability to take screenshots in the program). Is there any indication that progress is being made? Because this is making me start to worry about the future of LDD.

[efferman]

It seems there is a small bug with the new style curved panel

when i build the boom sections there is everything fine, but when i put the first stage in the mainbox the new panel type collides with something on one side. The old panel type would fit without problems, but it has not enough holes to get stable enough. does anyone know why this happens?

lxf

[Superkalle]

It seems there is a small bug with the new style curved panel

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.

[efferman]

Thank you very much

[Zerobricks]

And I fixed your arm

www.bricksafe.com/files/Zblj/Lego%20digital%20designer%20models/8.lxf

[efferman]

Thanks in advance!

Can you please tell me how you have done this?

Edited December 21, 2014 by efferman

[Zerobricks]

I removed all but one pin and rotated the panel to some 179,67 degrees Than I just reinserted the pins and copy pasted the panels.

Edited December 21, 2014 by Zblj