SylvainLS

@Stephan 26287 was modified too (connectivity)

Update 2020-06-30 Match colours with LDraw (ldconfig.ldr 2020-05-11). md5sum: e97e1c5f2d8e37f91abfa67031bc042a

There’s no tool for that in Studio, you’ll have to “work out the right angles and ratios” or use another application. As for the connect tool, it works this way: you select one part (or more), all the possible connectors appear, you select one, then when you hover over a part with compatible connectors, these connectors appears, you select one, and the selected part(s) is(are) moved so that the two selected connectors are connected.

Yes, original .lif are to be moved or the folders aren’t read. But my LDDExtended folder is never read. It’s only read when in a .lif. Yours is read as a folder? You need a good text editor (not notepad, not wordpad, maybe notepad++?), one that can open “binary” files and show and let you input control characters without breaking anything. Open MaterialNames/EN/localizeStrings.loc (or DE). You’ll see it’s just one long string: 2^@Material1^@White^@… or more accurately a series of zero-terminated strings (or null-terminated strings). (“^@” is the standard way to show the character of ASCII code zero. Depending on your editor, you might see \000 or 0x00 instead. If you don’t see anything, try another editor.) The first string is “2”. I guess it’s a file type or it says that strings need to be read in pairs. Anyway, you see that every next string is Material### (### being a number), and every other string is the name of the colour LEGO codes as ###. E.g. the first two strings (after “2”) say “Material1” is “White”, and LEGO’s code for White is 1. So you just need to add at the end “Material353”, then insert a NULL / zero, then “Vibrant Coral”, then another NULL. In short, you add “Material353^@Vibrant Coral^@”. Be careful not to add spaces (nor linebreaks), especially not in “Material353” because that’s the key LDD uses to match to “Vibrant Coral”.

Yes, I used your LIFCreator.py tool but there was no update inbetween the tests, so, unless it’s dependant on the date or a random value, the error is mine

It’s even simpler than that: contrarily to Assets(.lif) or db(.lif), LDDExtended has to be a .lif, not a directory. So, extract LDDExtended.lif, add the colours ID to MaterialSelector.xml, recreate the .lif, and it works¹. What’s “funny” is that LDD puts colours into the solid or transparent sections all by itself. (Colours in CurrentMaterials go into the Solid or Transparent sections according to their alpha channel, if they are in shinySteel (and not transparent), they go into the Metallic section, and if they are not in CurrentMaterials, they go into the Legacy section.) (¹To be precise: I was doubtful LDD would copy files in the user profile but still prefer to use the ones in Assets, but I tried anyway. First, I tried on the extracted LDDExtended/ in extracted Assets/: it didn’t work. Then on a recreated LDDExtended.lif in extracted Assets/: it worked. Then I put the original LDDExtended.lif back in extracted Assets/ and put the modified LDDExtended.lif in my user profile: it worked. I then removed the extracted Assets/ to use the original Assets.lif and it still worked. I tried again in a directory: it didn’t work. So it really needs to be a .lif. You can even leave the extracted directory, it will only read the .lif. What puzzles me is that I had tried with a .lif before, when I said it didn’t work (hence my remark in the other thread on LIF-Creator working well for me on the small LDDExtended.lif) but I must have made an error somewhere (in a name?) because now it works well.)

New info: even with 3+GiB of free memory, it gets oom-killed for a 1GiB db. How much memory do you guys have? And isn’t the sluggishness simply due to swapping?

Nope. I thought too at first but this file has just one “grid” element and the LDD palette is divided in different grids, but I tested anyway and it did nothing. It’s the same file that’s in Assets.lif and there’s no other candidate file, so I don’t know where the colour palette is really defined. On that note, I also thought about trying to modify LDD.lif with the info from Studio’s “ADP Palette” but never got around to do it….

I didn’t try again on db/. I would need to kill other applications first (I’ve 4GiB on this PC, about 1.5GB are free). It worked on LDDExtended.lif though (2 files…). It seems to be running fine: file names going rather fast. It “exploded” after only 20s or 30s for db/.

The Materials file is just an XML file. You can add (or change) any colour you want by adding a Material element: <Material MatID="353" Red="255" Green="109" Blue="119" Alpha="255" MaterialType="shinyPlastic"/> Then, the almost tricky part is to associate a name to the colour (otherwise, it’s named “??Material353??”). For that, you need a real editor to edit MaterialNames/{EN,DE}/localizedStrings.loc. It’s a bunch of zero-terminated strings (so stupid editors will think it’s data). The strings come in pairs: one is Material## and the other is the fancy name. So you just add “Material353^@Vibrant Coral^@” (where “^@” is the character 0) at the end and it’s done. Now, the real tricky part is to add it to LDD’s palette. But the palette isn’t in the user’s db.lif, it’s general to the application. I added the IDs to CurrentMaterials.xml too but it doesn’t seem to do anything. So, for now, I just edited the .lxf…

Just for information: I tried on Linux (my LDD is in Wine) and it was killed because it took too much memory. I guess you’re building the whole db.lif in memory first. Might need a warning in the readme or something….

Be sure to desinstall LDD first, especially you user’s directory, delete db.lif (did you already install the new bricks? delete the db directory).

Wait a second, your category icons are wrong. The antenna isn’t used in 4.3.11 and the interrogation point in the last one shouldn’t be here at all (it shows when a category is missing its icon). Are you really using 4.3.11 or did you install the messed up 4.3.12? Or did you made other changes to the db? Look in Help | About (F3), on the right, Brick Version should be 2670.

Theoretically, Windows has a POSIX compatibility and accepts / too. But then, it’s Windows….

I’ll send you one in a PM tomorrow. IRL, the gasket + piston + head form a block and the cylinder + cap (+ base for some) another, so, ideally, the LDraw parts should reflect that and people should use them that way. If/when the parts don’t exist or people don’t use them, it’s more logical that they use the separate subparts, all of them. That makes the piston 3 parts. I don’t think people would use a piston+head part and the gasket separately unless it comes from an LDD export or they know they need to in order for their model to be importable by LDD. But then again, the parts exist, so maybe people do use them this way. Anyway, I guess what I’m really complaining about is that LDraw allows many combinations of parts and ready-made assemblies (“shortcuts”) and not all of them are importable in LDD. I’ve the idea of making a more robust ldr2lxf conversion tool buzzing in my head sometimes. A tool that would try and look into the .dat files it can’t import directly to see if they are shortcuts of parts it can import, looking for undecorated versions, etc. But that’s more work than I’m ready to do now for the use this tool really would have. So it buzzes out quickly

Okay. It’s just that as IRL they are different parts, I thought that maybe some people depend on the correct one to be used for buying them or something. I too check LDraw parts and names thrice and still manage to make errors I just realised the motor needs the wheels too and I’m exporting it without Another solution is to leave 2686 as 2686.dat + 2x 2688.dat but make the whole motor, without the connectors, a unique part. IRL, only the connectors move (and the wheels, but they always look the same). The choice is yours. It depends on which solution is easier for you. That’s what I feared. The gasket allows to have two parts, so LDD can be tricked, but the LDraw models will use gasket+piston+head as one part so they won’t import. And that doesn’t help with parts that don’t have a gasket. Well, on the other hand, I’m not even sure many people import LDraw models in LDD these days (I generally only did it to adjust actuators length) and there are many other problems (decorated parts, official submodels…). So I guess that, sometimes, we’ll have to do with “good enough” for both worlds. No, this is okay because the parts form a “mechanical assembly.” It’s just that LDraw didn’t have it (some of these assemblies were already there, some weren’t). Part authors don’t always make all the needed “shortcuts.” They make the subparts and a complete, immovable part but not the useful middle level parts: if you don’t want a completely extended or completely compressed pneumatic thingy, you need to chase down the four or five subparts instead of the two that should be needed. I have submitted the 8 missing ones and I see no real reason for them to be rejected. It’s even a good way to find such missing parts Of course. I wasn’t blaming or even complaining (well, just a tiny bit: I’m French, we complain), just trying to explain from that point of view. My explanations often come a bit harsher than intended.

@Equilibrium I’ve added the conversions for the new parts and new assemblies in ldraw.xml and there are a few problems The first one is a tiny problem: 41475, 74741, and 75348 don’t appear when you search for them in LDD. Maybe it’s because they are listed as aliases in 95292? (It’s not a problem for ldraw.xml as they are the exact same assemblies. It’s just that there’s only one part available now.) Next, a part number error: 9388 doesn’t exist as a piston head, there’s a u9388.dat which is a train base and, for pistons, there’s u9338.dat which is a gasket. More below. One more troubling problem is that you merged several LDraw parts into one LDD part while the composite doesn’t exist in LDraw. That means the LDD part can’t be exported. Example: the monorail bogey 268600, you made it as two parts, 2697, the pivot, and 2686, the assembly of the bogey and the wheels (2x2688). But in LDraw, there’s no 2686+2x2688 assembly. There only is 2686, 2688 and 2697 as separate parts, or 2686c01 with all of them (so with a pivot frozen into place). And I’m not sure a new 2686+2x2688 assembly will be accepted (though the wheels don’t change when they turn, so having them fixed could be accepted). I think it would be better if 2688 was its own part in LDD too, but I’ve submitte a mechanical assembly with 2686 and 2x 2688. Another problem is the way you allow the pneumatic pistons to move: you make the piston head a rotatable part. IRL, it’s the whole piston+head that rotates, no? The problem here is again that there’s no match between the LDD parts and the LDraw parts. LDraw is missing some “mechanical assemblies” (assemblies of parts that always go together in a fixed way: no rotations nor translations between them), like complete cylinders with cap (but no piston+head). A logical distribution / assembly for a complete pneumatic piston is to have the whole cylinder in one part and the piston+head in another part. The piston+head moves and rotates inside the cylinder, so they should be kept together. LDraw users will either use the already formed piston (whole cylinder + piston + head in one part) or, if they exist, the whole cylinder and the whole piston + head, to adjust the extension. Example: 19475 should be two parts: the whole cylinder (which does not exist in LDraw, it’s 2 parts 2947b and 2941; I will be able to submit that part in LDraw) and the piston + head + gasket (2944c01). You made it three parts: the cylinder 2947 (merging LDraw’s 2947b and 2941), the “piston” 2944, but actually rod + gasket (so u9338 and part of 2944 in LDraw), and the “piston head” “9388” (part of 2944). This one I can make do for export: your piston + gasket is exported into the gasket only (u9338) and the piston head into the piston rod + head (whole 2944). But I can’t do anything for 26288: you split the piston+head in piston rod and piston head and those files don’t exist in LDraw. I can only export one of them and can’t import the assembly. Finally, you can see the little numerotation “errors” in the “changelog” for ldraw.xml (here). TL;DR: to import from / export to LDraw, we need a 1:1 match between LDD and LDraw parts. I’ve submitted to LDraw some of the parts that should be there but aren’t. But that won’t solve everything and it would be great if, at least in the future, LDD parts authors could try and keep that 1:1 match.

Update 2020-06-23 Added: 43086 / 43086.dat Panel Ramp Curved Turn 16 x 16 x 6 Added Custom parts: 2619 / 2619.dat Monorail Motor Box 2670 / 2670.dat Monorail Track Straight 4 x 8 2671 / 2671.dat Monorail Track Straight 4 x 32 2672 / 2672.dat Monorail Track Curve Quarter 2677 / 2677.dat Monorail Track Ramp Lower Section 2678 / 2678.dat Monorail Track Ramp Upper Section 2681 / 2681.dat Support 6 x 6 x 10 Stanchion 2687 / 2687.dat Monorail Base 4 x 20 2891 / 2891.dat Monorail Track Curve Short Right 2892 / 2892.dat Monorail Track Curve Short Left 35185 / 35185.dat Technic Gear 20 Tooth Double Bevel with Clutch on Both Sides 42531 / 42531.dat Technic Panel 9 x 2 x 3 Mudguard Arched #30 42545 / 42545.dat Technic Panel 13 x 2 x 5 Mudguard Arched #31 53178 / 53178.dat Technic Pneumatic Cylinder Bracket Added Custom assemblies: (Remember that one should use the correct subparts in the LDraw model for assemblies to be importable. Even though, some of these won’t be importable due to the way they were divided.) 19474 / 19474-f1.dat Technic Pneumatic Valve with Axle Hole (Neutral Position) 19475 / 19475-f1.dat Technic Pneumatic Cylinder 1 x 5 with 2 Ports with Stepped Outlets (Retracted) 19476 / 19476-f1.dat Technic Pneumatic Cylinder 1 x 11 with 2 Ports with Stepped Outlets (Retracted) 19478 / 19478-f1.dat Technic Pneumatic Cylinder 2 x 11 with 2 Ports with Stepped Outlets (Retracted) 19482 / 19482-f1.dat Technic Pneumatic Pump 1 x 1 x 6 with Stepped Outlet (Retracted) 26288 / 26288c01-f1.dat Technic Pneumatic Pump 2 x 2 with 3L Beam (Retracted) 47223 / 47223a-f1.dat Technic Pneumatic Valve with Pegholes (Complete - Neutral Position) 74982 / 74982-f1.dat Technic Pneumatic Pump 1 x 1 x 5.5 (Retracted) 268400 / 2684c01.dat Monorail Motor with White Motor Unit (Complete) 268600 / 2686c01.dat Monorail Wheel Chassis Assembly (Complete) 277400 / 74013.dat Monorail Stop/Go Switch 279300 / 2793c01-f1.dat Technic Pneumatic Cylinder 2 x 2 x 5 with 2 Ports (Retracted) 279700 / 2797c01-f01.dat Technic Pneumatic Pump 2 x 2 x 5 with Large Knob (Retracted) 288900 / 74780-f1.dat Monorail Track Point Right - Straight 289000 / 74781-f1.dat Monorail Track Point Left - Straight 324960 / 32495c01.dat Technic Wheel Spindle Steering Arm (Complete) 469400 / 4694c01-f1.dat Technic Pneumatic Valve (Complete - Neutral Position) 472240 / 47224c01-f1.dat Technic Pneumatic Cylinder 2 x 2 x 5 with Curved Base (Retracted) Modified Custom parts: 35186 Technic Transmission Driving Ring Extension with Eight Clutch Teeth 35188 Technic Changeover Rotary Catch 41682 Bracket 2 x 2 - 1 x 2 Up Centred md5sum: 2f7106d220b2900438d213cea7a4ea6c

It happened to others. You need to hide/unhide/resize the panels. Look in the Studio forum for the exact procedure.

Update 2020-06-18 Corrected: 62275.dat / 62275 ~Technic Linear Actuator 8 x 2 x 2 Piston (remove 1 LDU gap with Head) Torso assemblies Importable: 35298.dat / 62360 =Windscreen 3 x 6 x 1 Curved with Bottom Rectangular Stud Holder 35299.dat / 62360 Windscreen 3 x 6 x 1 Curved with Bottom Rectangular Stud Holder Added Custom parts: 35186 / 35186.dat Technic Transmission Driving Ring Extension with Eight Clutch Teeth 35189 / 35189.dat Technic Steering Wheel Hub with Brake Disc and 3 Pegholes 39367 / 39367p01.dat Wheel 14 x 48 with 4 Spokes with Integral Medium Azure Tyre 66606 / 66606.dat Panel Cone 4 x 6 x 10 Elliptic Parabolic Note: The custom version of 32235 is flexible, that means LDD doesn’t export nor import it anymore. (LDD doesn’t convert flexible parts.) md5sum: 6bfabef025776a883e309fc5193980ff

Ah, crap. I must have tested with the wrong ldraw.xml: that prevents the importation (because the assembly is still in ldraw.xml, LDD tries to make a non-existent assembly with the stick and the part). Still, a very simple solution to have the base and the stick separately.

@Corellian Corvette This is the right thread to ask. I’ve an objection / suggestion for this part though. The antenna is actually an assembly for LDD. That means several things: There’s already two parts: the antenna and the base. The numbers already exist. The “new” LDD parts would need new numbers (not a big problem but for the following), or they would still be only available in that assembly. When exported to LDraw, it’s just the parts that are exported. So new numbers wouldn’t prevent exporting them. When they are imported, you need the separate parts in LDraw and LDD reassemble them. The base (or the stick) part won’t be importable if it’s alone. So if we have a new part for the base, with a new number, it could be exportable but, as it would still be 4292.dat in LDraw, it wouldn’t be importable. We could make new assemblies with only one part (one for 4592 and one for 4593). LDD accepts that. But that would still confuse LDD when importing or that would mess up ldraw.xml for people who don’t use these custom parts. But all is not lost! There’s a much much simpler solution: delete Assemblies/73587.lxfml! The parts will appear in a new category at the end of the palette, with a “?” on a brick as icon. It’s because they are in the “LOOSE PARTS” group. That can easily be changed in their xml files in Primitives: replace the value of maingroupid with “236” and the value of maingroupname with “PLANTS, SIGNS AND FLAGS” (I’m not sure the name is useful). Changing the group in the xml won’t break the assembly for those who won’t delete it. But people will need to delete it themselves… or do we provide an empty/modified 73587.lxfml? @Equilibrium Sorry again about the renumbering but I really think it’s best to keep the official number easily accessible to users.

My idea was about parts with only one known combination, not to make one part for each possible combination. But that made me have two thoughts: Has someone looked into how to update the “standard LDD” part palette? All I know is that it’s not in the user’s db.lif. The colours (“materials”) are in the user’s db.lif. Wouldn’t it be interesting to have the new colours (Corail…) available?

24314 already was in LDD, so it’s an updated part, not a new one, no? 30010 was updated too (not mentionned). Also, 24314’s (now paintable) tire is too large (at least compared to LDraw). I’m wondering if it wouldn’t be more userfriendly to have the multicolour parts that have only one known colour, and will only have that one colour, be pre-coloured. E.g., 24314 only exists with a black tyre, so why not pre-colour the tyre as black? (It also only exists with a Trans-Clear wheel.) On the one hand, it’s nice to be able to colour the parts any way you want. On the other hand, some parts will never exist in other colours and it’s a bit tiresome to have to colour them bit by bit everytime. Just an idea….

No, it’s my fault with an incomplete renaming of a variable in the last update. It’s corrected now. Sorry. Good I’m following the addition of new parts in LDraw and here for LDD, so everything should be covered but if you find any part that’s missing or is wrongly converted, don’t hesitate to tell me. Studio can automate the making of steps: go in the Step Editor, select multiple parts, a “divide into steps” button appears. It’s about as good as LDD, I’ll let you decide if it’s good enough