nemo

They are already in LDD (it has those decorations built in), but many are not available through the UI. What you have to do is edit an .lxf file manually: Create a new file with only the piece you want to decorate Apply any available decoration to it Save it, then rename the .lxf file to end .zip Open that .zip, select the .LXFML file and press ctrl-C to take a copy. Go up a level and paste the copy next to the .zip Load that .LXFML file into your favourite text editor (or notepad!) Find the bit that says decoration="12345" and replace whatever that number is with one from the list Save the file, select it and press Ctrl-C to copy it, go inside the .zip again and paste it in there Go back up a level and rename the .zip to be a .lxf again, load it into LDD Select and copy the part with the new decoration Load your model and paste in your customised part Note that you can apply any decoration to any part that takes a decoration, but you cannot easily add decoration to parts that cannot normally be decorated. That would require a change to the assets.lif file.

Sorry to dig out such an old post, but this is an overstatement. It is specifically LEGAL under European Copyright Law for the licensed user (and for a free program, that means everyone) to reverse engineer a software program for the purposes of producing a non-competing interoperable program. There are provisos concerning defeating copyright-protection mechanisms and harming the vendor’s revenue potential (such as unlocking paid-for features), but those aside it is legal to inspect and (write an interoperable program that) modifies LDD’s data files. The EULA or TOS of course do not outrank European Law, and any terms they try to introduce to remove your rights are as invalid as those trying to invalidate the Sale of Goods Act or the Distance Selling Regulations. If the data files concerned were obfuscated in some way, then that would de facto rule out access in the US (thanks to the draconian DMCA law) and could constitute a “copyright protection mechanism” enshrined in the EU law. However, since such an interoperable program’s purpose would be merely to rearrange the data used by the copyright program (and not make copies, distribute, or remove copyright notices) it would be incredibly difficult to prove a copyright infringement in that case. But this theoretical case does not apply as of LDD 4.1.8. Edit: One interesting limitation is that though it is legal to reverse engineer under these circumstances, it is NOT legal to publish the results. So, you can modify LDD, you just can't tell people what you found while you did so – you can provide the “interoperable program” that does the modification, but you can’t say exactly what it does!

Voilà: 54580-54585, 54594-54595 55034-55035, 55059, 55071-55072, 55122-55130, 55132, 55135, 55146, 55148, 55159-55161, 55175, 55196, 55347, 55350, 55357, 55506, 55510-55511, 55513, 55518, 55660, 55662-55663, 55665, 55703, 55728-55729 56006, 56057, 56098, 56134, 56287-56289, 56571, 56753, 56756, 56918 57056, 57239, 57308, 57336, 57592, 57755-57756, 57818 58000, 58002, 58229, 58425, 58465, 58592, 58596, 58603, 58764, 58812, 58858 59487-59488, 59545, 59631-59632, 59645, 59715, 59717, 59878-59879, 59881, 59909 60114, 60147, 60153, 60382, 60488, 60690, 60763 61820 62292-62293, 62375, 62452-62453 63078, 63079, 63179, 63181, 63187, 63189, 63191, 63193, 63195, 63197, 63199, 63201, 63204, 63205, 63380, 63404, 63708, 63712, 63815 64274, 64352-64366, 64635, 64891, 64901, 64913, 64968, 64998 84672, 84678, 84759, 84760-84767, 84770, 84988, 84990, 84993, 84999 85008, 85013, 85111-85115, 85117, 85232, 85286 86216, 86295-86296, 86402, 86405, 86666, 86698, 86700, 86702, 86704, 86706, 86868, 86872, 86992, 86994-86995 87024-87025, 87032, 87037-87038, 87078, 87108, 87212-87214, 87217-87218, 87222, 87227, 87833-87836, 87874-87875 88132, 88154, 88169, 88171, 88173, 88175, 88177, 88180, 88182, 88184, 88186, 88188, 88190, 88192, 88194, 88247, 88252, 88256, 88624-88626, 88628-88629, 88632-88635, 88637-88640, 88642-88643, 88652-88655, 88657-88658, 88697, 88711, 88717, 88721, 88727-88731, 88933, 88934, 88936-88937, 88940, 88942, 88945-88946, 88948-88949 89151-89154, 89309-89313, 89316-89317, 89320, 89559, 89565-89573, 89587-89589 90942, 90946, 90957-90959 91340-91342, 91883 92168, 92824, 92883-92884 93074, 93077, 93200-93201, 93232-93238, 93300, 93304, 93319, 93321, 93337, 93338, 93584 94062, 94097, 94206, 94207-94209, 94216, 94264-94265, 94270-94272, 94274, 94335, 94874 96129, 96131-96132, 96154, 96703, 96705, 96708, 96723-96724, 96728-96729, 96731-96732, 96736-96737

This one is particularly strange. Start with an empty workspace and try to place a 3069 FLAT TILE 1x2 at the edge of the studded area in all four rotations. With one of the short sides at the edge of the studded area, the area automatically extends as though the brick overlaps! However, you can still place two 3069s end-to-end so this overlap must be microscopic.

2464 Facet brick, bottom: The length of the tubes has been fixed in 4.1.8, but bricks still attach at the end of where those tubes were, not in the 2357-shaped (L shaped) recess!

I wonder if any altruistic tech-head might already have unpacked, combined and repacked a .lif file containing everything LDD has ever had? (Or, bowing to copyright concerns, written an appropriate script to do so?)

I have to quote Kryten from Red Dwarf here: In other words, yes I really did have to write it in capitals. And that is precisely why they should be loaded in another thread so that the UI continues to work in the mean time. Again, a separate rendering thread would solve that – it could load the PNG quickly and then load the whole LXF slowly if it wanted. What it does and how long it takes does not matter if the user is not forced to wait while it happens! Ah, but did I mention how elegant and concise they are? I have no idea what you mean. I’m not QA yet. Nor senile. I dislike the way this forum concatenates unrelated replies just because they are consecutive.

I didn’t say it was junk, I have listed some of its flaws. Actually I quite like it, but it is more frustating and slow than it needs to be. I have built 139 significant projects using various versions of LDD, totalling 2.52MB, and I am a senior software engineer. Am I allowed to express an opinion now? To report the bugs and design flaws, obviously. I’m not proposing any additional functionality or tools, I’m applying what pressure I can to get the ones we have working properly. Claiming that the target audience is young is no excuse for sloppyness (the reverse, actually). Not much – the XML is not compressed. And since the XML is wrapped in a proprietary binary blob it cannot be accessed or edited... so there’s no point in it being XML in the first place. That just makes the file bigger, the reading slower, and requires an XML parsing library in the executable making that bigger too. .lif is closed. It’s not very complicated I grant you, but it can’t be trivially edited, or can it?

I'd like all the basic UI errors to be fixed. eg, when Ctrl-clicking to add bricks to a selection, who could argue that just missing the required brick and clicking in open space could possibly be legitimately interpreted as a desire to lose the entire selection? Whilst still holding Ctrl? Basic stuff. Lassoo selection should use the projected brick outline (or a convex hull of the projection) NOT the bounding box to decide what is inside the lassoo rectangle. Ctrl-lassoo should obviously not clear the current selection first. As I've reported elsewhere, the colour palettes must NOT be fixed size as they don't fit on a netbook screen (1024x600). The other thing I'd like is some more sensible data management. The massive binary blob of XML files that is the 400MB .lif (ignoring the oxymoronic construction itself!) is unnecessarily inefficient and causes a huge amount of delay. If you are going to use a binary format, then build in an appropriate index at the start so the whole massive file doesn't have to be scanned! No, I can't ignore the oxymoron: If you're going to have a binary file, don't inflate it and slow it down by filling it with now-useless XML, use a binary format. Or, if you're going to inefficiently define stuff in XML, then don't hide it in an uneditable binary blob! Do "welcome screen" thumbnail loading and rendering in another thread - stalling the UI thread so the user can't click the 'New' button until LDD has loaded and rendered a thumbnail of a previous model is yet more poor engineering. I know LDD is free but it has Lego's name on it, and that means the same degree of quality and attention to detail should apply to its engineering as to the rest of Lego's products. I find the LDD software frustrating, slow and frequently disappointing.

Apologies if this has been reported before, but as it has not been fixed in 4.1.8 and it's a SCHOOLBOY ERROR I can't help myself. The colour palettes (both the palette filter and the colour tool in various themes) are FIXED SIZE. This is an unforgivable error in a windowing environment in general, but when LDD is run on any netbook with the typical 1024x600 resolution, this is the unusable result: This affects multiple themes including Mindstorms and Extended, and is a serious UI design fault.