nemo

Yes. Anyone can make the classic 2×4 brick and other bricks of a similar vintage*, and any newly-invented part using compatible dimensions and techniques. Mind you, it’s quite another matter to be able to make such bricks to the quality that Lego (used to) make them. By all accounts BrickForge do a much better job than the cheap Chinese rip-offs. *Technically, recent Lego designs are also protected, but not by patent. I’ve no problem with the ‘generic’ bricks existing, but cloning of recent Lego brick designs is just IP theft. It’s easier and cheaper to register a design than get a patent, but it’s a much weaker legal instrument too. BTW I wonder whether you should change the “Lego” on those studs to “bbqqq” – after all, they are your designs. And if those images are linked elsewhere they might appear to be Lego sourced – Lego don’t like people using their logo without permission.

Now that the patent has expired, it needn’t be Lego that has to make these things. Perhaps Brickforge might be interested? Their splat part is particularly fun:

No, it takes a long time because it is single threaded, forcing the user to wait until it has loaded the .LXF and all the bricks and resources used by that file – and we know how unbearably slow the .LIF access is. The problem is provoked by large .LXFs, but it is caused by LDD. So to return to topic, what I want in LDD5 is massively improved data access times and multithreading... just having an additional UI thread would make a big difference.

It is a pity that parts aren’t in more than one section. They should be where you look!

Search for “door”. Marvel at the variety of categories for the simple pairs of doors.

Because as we know, Maya works by voodoo magic and not by the same software engineering techniques that could have been employed in LDD. It’s a cruel, cruel world...

Yeah, that’s what I did too, but I think it should be a headlight brick at the top? Anyway, I wasn’t able to fine tune it well enough. Well done!

I think they may be cheating with the fire escape. There's no room for 48729.

Well the “advanced graphics” aren’t an option on a netbook, apparently.

I’d like to see LDD MOCs have their own subforum, to separate them (numerous, few replies) from the discussion threads (fewer, many replies). And I’d prefer to in the emoticon list – it’s much clearer and more standard. says “meh!” to me.

I run LDD on a 1GB netbook! I don’t dare install it on one of the work machines.

If they’re the same, there’s no problem. If they are different then it is just the same as copying 12345.g into a directory containing 12345.g – LDD would ask which one you wanted to keep. It could display both side by side in 3D, or in context in the model. Or it could just rename the second to be 12345(2).g (adjusting the loaded .lxf accordingly). Obviously if you allow custom parts in LDD, then it needs a way of managing them, but this isn’t a difficult problem. Well that’s a separate problem. I’d solve it by having a namespace for any non-official part number and have LDD map equivalent parts. There’s already the many-to-one mapping of brick/colour number to mould number. There’s no reason why one couldn’t have BL:12345.g for example. If we are talking about functionality built into LDD, then that question doesn’t arise. If we are not talking about LDD functionality, then the only thing one can do is modify or unpack db.lif and add the .g etc files manually. A stand-alone “interoperable program” would be the easiest solution to that. What are we talking about – new LDD functionality or a third-party hack? If it’s LDD functionality then one would hope they wouldn’t introduce any more bugs. If a third-party hack then you cover it with “THIS IS A HACK” warnings. You say “If you use this facility it may stop your copy of LDD working and you may have to uninstall the hack”. Then you provide a mechanism to return to the original db.lif and LDD returns to its original state. That would be very nice, though it isn’t necessary. There is this very forum! Again, namespaces are the solution to that. Actually it’s stickers, rather than bricks, that I anticipate would proliferate most. They’re much easier for the average user to produce, and there are probably more stickers missing from LDD than bricks. Managing namespaces for custom stickers is more tricky, and would probably necessitate very long Android-style identifiers: eg com.eurobricks.forum.nemo:12345.png Wouldn’t it be nice if Brickarms could provide a definitive set of digital parts though? There’s rather more to software engineering than typing, but this is what I do so it doesn’t seem so hard to me.

In most editors that is known as “grouping” and yes, it is essential! And grouping other groups should not “flatten” them into a single group of pieces – the inner groups should stay grouped.

Yes, it was to that travesty I was referring. It had me very confused after that update. To be fair, as various brick groups are merged before being shown in those tabs, it is not a given that changing a brick group will move it to a different tab. But even a little QA would have made a lot of difference here.

The .lxf file is just a zip, so could contain any non-standard resources. In principle this is no different to including the correct images and fonts in an .xps or .odt file. Then if someone adds a sticker they could send you an .lxf containing the brick and its sticker which you could then copy and paste, or add to your own repertoire.

That’s not really the best tool for the job, but rest assured that the .lif file format is fully understood (it’s quite simple). However, currently it’s a bit of a trek to move a brick – each brick says which group it is in, then various groups are merged under a single icon. (I’m going to stop using the word ‘palette’ as that has a slightly different meaning within the Assets.lif structure). So although there are group icons like the one attached, they actually contain bricks from multiple groups for which there are no icons. This means there are a number of files within the .lif that would have to change just to move one brick. Which is why we were discussing LDD having user-customisation so this huge chunk of data doesn’t need to be changed to move WALL ELEMENT 1x2x1 back into the group that bears its icon!!!

Is that actually true though, or does it only look in db.lif if it hasn’t got a \db\ etc? LDD certainly doesn’t work if I add an empty \db\, so I assume it looks there first.

Until selected. They disappear, then reappear, with a yellow background! You could create new palettes, and you’d choose the palette icon from the available range in that version of LDD. That palette disappears. When you create a new palette you choose which of the palette icons to use. Yes. The minifigure accessory palette is very nearly there already! These are simple scalability questions which a competent programmer naturally considers... apropos of nothing. You should be able to reorder. You can only move the bricks out of a palette, you can’t “delete” it. It comes back with those new bricks in it. With yellow backgrounds! Really? You should see how complicated it gets once you have to express it in code. It’s certainly not a three line change (of which two are a comment).

The .lif isn’t too bad. And in fact it isn’t necessary to rebuild it. Generating the .g mesh files is not trivial though. What software is used to build those?

Crikey! It would be good to be able to “fix” certain bricks in place and then allow other hinged parts to move freely (a FEMS implementation). Not trivial though.

New bricks get added to the Lego appointed palettes (and could have a yellow background to show that they are new!). User can then move them. All PCs support multiple users, so as long as the customised palette setup is stored in the user's AppData directory then users' changes would not affect each other.

And from a technical point of view it's disappointing that these palettes are not user-editable. It would be simple to allow the user to drag or copy bricks from palette to palette, or indeed to add more palettes.

Simple, and like all great ideas, obvious in retrospect.

You are entirely free to do that. No software company could claim to “own” some part of your hard disc, even if that appears to be inside “its” directory.