Custom LDD bricks and fixes

[C3technic]

Yes, I saw this tool, but it is too complicated, or does not work, or I am noob (yeah I am really computer noob). I can't get the same results, tried many times, that's why I ask - not what tool I need, but how to use that tool

[Anton]

When i open tracks/rails section, the programm crashed. Also, what mean attribute 'brick version'? My brick version is 777 while you version is 2670. It is problem? If it is, how i can change it?

[M2m]

On 2/28/2021 at 8:27 PM, Anton said:

When i open tracks/rails section, the programm crashed. Also, what mean attribute 'brick version'? My brick version is 777 while you version is 2670. It is problem? If it is, how i can change it?

This means you go the broken LDD Version from Legos website :(

Steps to solve:

1. Uninstall Lego Digital Designer

2. Delete this folder also (otherwise a reinstall will not work):
   C:\Users\<YOUR USER>\AppData\Roaming\LEGO Company\LEGO Digital Designer

Then get the good version from here

• https://web.archive.org/web/20190622153357/https://lc-www-live-s.legocdn.com/downloads/ldd2.0/installer/setupLDD-PC-4_3_11.exe

[Anton]

Cool! Thanks!

[Graham-S]

A quick daft question ( or 3 . . . ) for those in the know . . .

Are Mac users affected by the issues with the LDD version direct from Lego ??

If so, where could they download the good version from ??

My project is almost ready - what worked in LDD needed a few small tweaks once I got the bits from Lego - and I'm going to do a little website for it including the LXF files and software.

I'll post a link for that when it's up - where's the best place to post details of a random daft machine made with Technic bits and bobs ??

 

Thanks in advance.

[SylvainLS]

26 minutes ago, Graham-S said:

Are Mac users affected by the issues with the LDD version direct from Lego ??

Nope.

AFAWK, 4.3.12 was an attempt to solve 4.3.11’s installation problems on Windows 10 (LDD comes with a “Flash Player Active X” crap that doesn’t want to install while it’s absolutely not necessary nor useful, at all), so TLG solved the installation problems but the included Bricks library is way outdated and the program can’t get on the internet to download a more recent one.  Total crap.  Unfortunately SOP (standard operating procedure) for big companies.

[M2m]

11 hours ago, SylvainLS said:

Nope.

AFAWK, 4.3.12 was an attempt to solve 4.3.11’s installation problems on Windows 10 (LDD comes with a “Flash Player Active X” crap that doesn’t want to install while it’s absolutely not necessary nor useful, at all), so TLG solved the installation problems but the included Bricks library is way outdated and the program can’t get on the internet to download a more recent one.  Total crap.  Unfortunately SOP (standard operating procedure) for big companies.

Yes can confim the macOS version you can get from LEGO site is good (in the sense that it includes the lastest brick library Lego ever released officially), the Windows Version is as SylvainLS explains.

Caveat for the macOS version of LDD: it is 32bit software only so the latest macOS version you can use to run it is macOS Version 10.14: "Mojave". Later versions of macOS dropped 32bit software support.

[Graham-S]

Thanks guys.

Isn't it great how updates usually cause no end of problems for existing apps . . .

[Stephan]

Guys, I need your help. Something is going crazy and I am struggling with this problem for 2 days now.

I was correcting the 3D file for 2454, and in the meantime adding 2454b (24541) and 46212. Which are 3 variants of the 1x2x5 brick. But when I place 46212 in a file and reopen the file, 46212 turned into 2454. But the *.xml file of 46212 does not contain an alias or something else that references to 2454. So I think some link is made in LDD or another file somewhere. If someone has some time to puzzle with this, it would be amazing. These parts are stopping the progress for the new update since I want to include them.

The files can be found below (2454 and 46212 are decorable, so two *.g files are included for both). Please make sure that you back-up your original 2454 *.xml and *.g files! This version from the link now includes the ridges on the inside and has updated collision data to make it hollow. 

Link to parts.

Edited March 9, 2021 by Stephan

[M2m]

6 hours ago, Stephan said:

Guys, I need your help. Something is going crazy and I am struggling with this problem for 2 days now.

I was correcting the 3D file for 2454, and in the meantime adding 2454b (24541) and 46212. Which are 3 variants of the 1x2x5 brick. But when I place 46212 in a file and reopen the file, 46212 turned into 2454. But the *.xml file of 46212 does not contain an alias or something else that references to 2454. So I think some link is made in LDD or another file somewhere. If someone has some time to puzzle with this, it would be amazing. These parts are stopping the progress for the new update since I want to include them.

The files can be found below (2454 and 46212 are decorable, so two *.g files are included for both). Please make sure that you back-up your original 2454 *.xml and *.g files! This version from the link now includes the ridges on the inside and has updated collision data to make it hollow. 

Link to parts.

I see there is a difference in these parts (LEGO PART 2454b Brick 1 x 2 x 5 with Hollow Studs and Bottom Stud Holder with Symmetric Ridges | Rebrickable - Build with LEGO) But does this difference make a difference build-wise ? I get 46212 can slide in reality but for the other two parts does their use differ ?

[Stephan]

56 minutes ago, M2m said:

I get 46212 can slide in reality but for the other two parts does their use differ

Not really, I could omit 2454b though. But 46212 is used in modern sets for transparent parts.

But omitting 2454b still gives the issue.

[M2m]

1 hour ago, Stephan said:

Not really, I could omit 2454b though. But 46212 is used in modern sets for transparent parts.

But omitting 2454b still gives the issue.

Are you sure you overwrote the original 2454.xml in the db folder correctly? Maybe you should delete it (make backup 1st).

I see the original has an alias for 46212 as you can see below: 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<LEGOPrimitive versionMajor="1" versionMinor="0">
  <Annotations>
    <Annotation aliases="2454;46212"/>
    <Annotation designname="BRICK 1X2X5"/>

 

[Stephan]

Yes, I have. The new parts are included in the link. I removed all aliases.

[Stephan]

It appears to be hard-coded somewhere or something like that.
Removing the 2454 file works fine for 46212, until you reopen the LDD file, then the 46212 part gets removed...

I have decided to leave it as it is for now 

Edited March 10, 2021 by Stephan

[Kuramapika1]

@Stephan: I downloaded the files and haven't any problem with them.

[Stephan]

6 minutes ago, Kuramapika1 said:

I downloaded the files and haven't any problem with them.

If you place the 3 types of pieces in a LDD file and reopen the file, 46212 is still there?

[Kuramapika1]

1 hour ago, Stephan said:

If you place the 3 types of pieces in a LDD file and reopen the file, 46212 is still there?

It changed to 2454 automatically.

[M2m]

Interesting phenomenon. I can confirm that 46212 is also replaced in my LDD. 

I did several other tests like deleting 2454, 24541 and 46212 (xml and all g files) and creating a completely new part for 46212 with a wig geometry (2454 and 24541 still deleted).

After saving a new build lxf-file with the test 46212 part and reloading it in LDD says 1 brick couldn't be loaded and will be removed. In a further test I completely removed my assemblies folder (just maybe to ensure there is no interference there) and I couldn't get part 46212 working. Maybe 46212 is blacklisted somewhere in LDD ?

Update:

Just renaming 46212 to 46213 fixed the problem for me. I think its kind of a bug (or undocumented "feature"). Maybe somewhere hardcoded in LDD.exe ? I did all my tests on Windows 10 by the way. I'll look into macOS later.

Update2:

Same on macOS 46212 will replaced

Edited March 11, 2021 by M2m

[Graham-S]

Thought for you - would it solve the problem or really mess things up if you tried sticking a suffix on the end of the part number, say 46212-A ??

Hopefully that'd stop the LDD Find-Replace from recognising it and changing it, perhaps

[Kuramapika1]

The problem is in the part 2454. Five minutes ago, I use another part (mesh) with the number 46212 and it allow me to use it. Somehow, part 2454 retains some unknown info on the .g file.

[Stephan]

35 minutes ago, Kuramapika1 said:

Somehow, part 2454 retains some unknown info on the .g file

But if you delete the *.g file and copy another file and rename it to 2454, you still get the same problem, so it's not coded in the *.g file in this case. I think it has to do something with the way LDD Regular mode uses aliases while LDD Extended does not.

[polymaker]

Well... I've reverse engineered LDD and I just found out that there is a bunch of hard-coded "aliases".

I've stepped through the loading of a model file with the part 46212 and I stumbled upon this

It translate to:

compare memory value to B484 (hexadecimal for 46212)
if the memory value is equal replace memory value with 996 (hexadecimal for 2454)
otherwise continue

There is a bunch of other comparisons. I will try to make a list of them all.

Also I might be able to create a patch for LDD to prevent this behavior. I don't have a lot of experience doing so but I know it is possible.

Edited March 11, 2021 by polymaker

[SylvainLS]

9 minutes ago, polymaker said:

Also I might be able to create a patch for LDD to prevent this behavior. I don't have a lot of experience doing so but I know it is possible.

Whereas finding the list could fall under “interoperability,” I believe that’d be over the line of what is lawful.

(IANAL)

[polymaker]

50 minutes ago, SylvainLS said:

I believe that’d be over the line of what is lawful.

Yes you are right. I didn't think of that 

Anyway here is the list so far:
part id => replaced by
30007 => 4215
32239 => 6588
41070 => 32008
45173 => 42060
46212 => 2454
47577 => 93565
52035 => 89536
57722 => 71986
59577 => 57558
60677 => 55676
60700 => 6015
61988 => 53788
63021 => 62699
63153 => 61804
64871 => 32278
82610 => 4034
86210 => 60603
86209 => 60601
88513 => 53451
88701 => 87777
89500 => 85961

There is another set of part IDs that are checked but those are not replaced by another ID, rather they seem to have a special behavior. I'll post what I find.

Edited March 11, 2021 by polymaker

[M2m]

2 hours ago, SylvainLS said:

Whereas finding the list could fall under “interoperability,” I believe that’d be over the line of what is lawful.

(IANAL)

IANAL: How would a patch like this be different from patch of let’s say Diablo 2 that gives you unlimited money ? 
 

On another note i wonder why these replacement pattern were hard coded into LDD ?

Edited March 11, 2021 by M2m