SylvainLS

Eurobricks Knights
  • Content Count

    999
  • Joined

  • Last visited

5 Followers

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)
    <p> Classic Space </p> <p> Go Brick Me! </p>

Profile Information

  • Gender
    Male

Extra

  • Country
    France
  • Special Tags 1
    http://www.eurobricks.com/forum/style_images/tags/LDD_builder_yellow.gif
  • Special Tags 2
    http://www.eurobricks.com/forum/style_images/tags/ldraw_builder.gif

Recent Profile Visitors

2951 profile views
  1. @Stephan 26287 was modified too (connectivity)
  2. Update 2020-06-30 Match colours with LDraw (ldconfig.ldr 2020-05-11). md5sum: e97e1c5f2d8e37f91abfa67031bc042a
  3. SylvainLS

    Hinge Align in Stud.io

    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.
  4. 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”.
  5. 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
  6. 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.)
  7. 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?
  8. 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….
  9. 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/.
  10. 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…
  11. 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….
  12. 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).
  13. 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.
  14. Theoretically, Windows has a POSIX compatibility and accepts / too. But then, it’s Windows….
  15. 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