M2m

This is normal. I pushed another update. Do you get any other output with the latest update?

Yeah - there should be. I pushed another update into github. I really hoped folder processing is standardized in Python...

Hmm... do you get any output ? For me it looks like m2ms-MBP:LegoToR m2m$ ./LIFCreator.py /Users/m2m/Library/Application\ Support/LEGO\ Company/LEGO\ Digital\ Designer/db/ Choosen directory: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db Will create: db.lif Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MaterialNames/DElocalizedStrings.loc Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MaterialNames/ENlocalizedStrings.loc Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/Assemblies76537.lxfml Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/Assemblies64786.lxfml Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/Assemblies99415.lxfml ..... .... Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MainGroupDividers226.png Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MainGroupDividers385.png Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MainGroupDividers218.png Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MainGroupDividers225.png Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/MainGroupDividers351.png Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/info.xml Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/CurrentMaterials.xml Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/DecorationMapping.xml Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/Materials.xml Adding: /Users/m2m/Library/Application Support/LEGO Company/LEGO Digital Designer/db/pes.xml COMPLETED: 11806 files processed and added to db.lif.

I'm having a 2017 Macbook with a i5 2.7GHz and 8GB RAM - so nothing too new. It takes about 35 secs on my machine to create the db.lif (which is the original + all the new parts) and the file is around 1.04GB. It should create the file in the same dir where you started the script from. Now you already ran the script 4 time (db_4.lif). It will check if a file is already there with the same name and create a new one (and not just overwrite the file).

Very sorry to hear :( I'm totally aware that folder parsing in Windows vs Linux vs Unix (macOS) is quite s**t I made some updates to print out all files it is trying to parse. Also (stupid) macOS comes with python2.7 and you are using 3.7 (I know 2.7 is out of support already - I blame apple for that). Maybe you can give it a try. Be aware you have to press a key twice for it to start.

I checked blueprint 0.26 and I had some succes in loading some new parts While on most of my files using new parts I got this error: Not sure if it is related to particular parts and which ones...

I assume that command is more or less correct (which you have to start from the command prompt - cmd.exe) LIFCreator.py \Users\Albert Penello.000\OneDrive\Lego Creator\LIFE Extractor\db\ Depending on what version and where you installed it you may have to start as ( this assumes you have installed Python2.7 in a directory C:\Python27) C:\Python27\python.exe LIFCreator.py \Users\Albert Penello.000\OneDrive\Lego Creator\LIFE Extractor\db\ Do you get any error message or any output ? What happens if you just type python into the command line ?

Try this: If you have a link to the latest Blueprint I could check it myself on macOS.

I finished a Python program that (re)creates a lif file from a folder structure. So basically you can first use LIFExtractor.py (by JrMasterModelBuilder) to extract db.lif, then add mods and new bricks and afterwards repack the modified db folder with this tool (LIFCreator.py). It is tested on macOS 10.14.6 and Windows 10. It worked with LDD 4.3.11, bluerender 0.6 (that is the new added bricks where loaded and rendered) and of course I also tested it with JrMasterModelBuilders LIFExtractor.py (packing with this tool, unpacking with JrMasterModelBuilders LIFExtractor and vice versa). Still I don't guarantee any functionality and suggest you to keep backups (especially of the original db.lif). WARNING: You accept full responsibility of using it yourself ! https://github.com/sttng/LIF-Creator How to: ./LIFCreator.py /Users/your_user_name/Library/Application\ Support/LEGO\ Company/LEGO\ Digital\ Designer/db On Windows type the following into the command-line LIFCreator.exe "C:\Users\<YOUR USER>\AppData\Roaming\LEGO Company\LEGO Digital Designer\db" Below a bluerender test (the leaves are a new custom part):

Ok I finished a python program that (re)creates a lif file from a folder structure. So basically you can use LIFExtractor.py (by JrMasterModelBuilder) to extract db.lif, then add mods and new bricks and the repack if with that tool: LIFCreator.py. I tested it on macOS and it worked with LDD and bluerender 0.6 (that is the new added bricks where loaded). https://raw.githubusercontent.com/sttng/LDD/master/LIFCreator.py How to: ./LIFCreator.py /Users/your_user_name/Library/Application\ Support/LEGO\ Company/LEGO\ Digital\ Designer/db/ (mind the trailing / after db - this is important). As said I didn't (and can't) test it on Windows - I don't have Windows privately. But I welcome any feedback and hope it works in Windows as well. Below a bluerender test (I think the leaves are a new custom part):

Thanks for the offer. But I think the tool is simple enough and wouldn't justify donation. Anyway it's just I'm too rusty in figuring folder recursion out (I have a prototype which packs all files in one folder into a lif file without subfolders. This unpacks flawless with LIFExtractor. But without proper subfolder processing this is useless.) Once its done I will release the full source - its python.

Working on a lif repacker, but having some trouble in getting the recursion (for folders and subfolders) right. Meanwhile I’m sure you can reach out to msx80 and asking for changing blueprint.

Yeah I'm looking for a "LIF Creator" tool as well. Maybe I spend some time on the weekend to look into coding my own LIFCreator in Python. Alternatively maybe bluerender and blueprint instructions creator could be updated to read from the extracted file structure (I updated my own RenderMan converter to read from the DB folder structure if it is available).

Credits shall be given to the original parts author as part of an xml comment inside the primitive xml file like for example this: <!-- Derived from The LDraw Parts Library Orginal Author: Steve Bliss [sbliss] Editted for LDD by Jester94 --> There isn’t a standard for numbering but as official LEGO updates are unlikely just go with what you think fits best. In case this problem arises later it can be handled relatively simple with part rename and text search replace in the lxfml file of the model. stephan is curating a list and zip file of all new parts. So I think if you just put your new parts somewhere to make them available it’s fine. Of course any suggestions to the issues are welcome.

This looks useful! Thanks for sharing !

I know there is LIFextractor out there to read and extract LDD lif files. But is there also the opposite ? A packar or creator which stores folders and files in a lif archive ?

Nice bab 5 station there !

Check this out (it’s Mecabricks but not animation) https://www.brothers-brick.com/2020/05/30/when-we-all-learned-to-sit-thought-the-credits/

Just made a trial modification / correction of 1104.xml. If the below is an acceptable way of using LDraw Parts (the file loads in LDD), my suggestion would be to handle this like this. <?xml version="1.0" encoding="utf-8"?> <!-- Derived from The LDraw Parts Library Orginal Author: Steve Bliss [sbliss] --> <LEGOPrimitive versionMajor="1" versionMinor="0"> <Annotations> <Annotation aliases="1104" /> <Annotation designname="Antenna 6H" /> <Annotation maingroupid="236" /> <Annotation maingroupname="SIGNS, FLAGS AND POLES" /> <Annotation platformid="200" /> <Annotation platformname="SYSTEM" /> <Annotation version="1" /> </Annotations> <Connectivity> <Axel type="7" length="1.16" requireGrabbing="0" startCapped="1" endCapped="0" angle="90" ax="0" ay="1" az="0" tx="0" ty="0.12" tz="0"/> </Connectivity> <Bounding> <AABB minX="-0.2" minY="0" minZ="-0.2" maxX="0.2" maxY="5.8" maxZ="0.2" /> </Bounding> <GeometryBounding> <AABB minX="-0.2" minY="0" minZ="-0.2" maxX="0.2" maxY="5.8" maxZ="0.2" /> </GeometryBounding> </LEGOPrimitive> Thoughts ? Suggestions ?

The pizza texture works for me out of the box on macOS without ever having touched the PNG.

Yeah you're right. Still it should be tested before just asking everyone to add <!--- Comments --> The parser is https://github.com/libexpat/libexpat in LDD.

Not sure if the xml files support comments. While technically just text files it depends on the flexibility/strictness of the parser to support new/custom nodes. Will play around with this after work.

Don’t think the g parts support that. I guess adding a txt file (per part ?) can be done. On the other hand „The LDraw Steering Committee (SteerCo) also holds an attribution to 'The LDraw Parts Library' in such Derivative Works to be sufficient in lieu of a full list of authors.“. So it seems that crediting the LDraw Parts Lib in general is ok too. How does stud.io do that ?

Good point ! I may be wrong here. Your 20460 comes with 2 parts (g, g1). The original 20460 comes with 5 parts (g, g1, g2, g3, g4). If I want to use yours should I delete all original g, g1, .., g4 files ? In that case your original xml files was correct. Sorry my bad. I just overwrote the g and g1 file with yours, keeping Legos g2, g3 and g4. I am using a hex editor to look at the raw data (0xED is the name of the editor). The .g file format is fairly well documented here: https://github.com/Polymaker/ldd-modder/blob/develop/Documentation/G (mesh) file structure.md You can check lego's own .g and g1, g2, g2, gX files for comparison. The non-flex .g files always have a standard mesh (Hex: 0x3A Dec: 58) indicator according to my experience. The g1, g2, g3, ... files may have a Textured mesh (Hex: 0x3B Dec: 59) indicator (if they are able to be textured) and then also UV mapping info.

35660 - LEGO Hair with Cap has a bug in the .g file. Typically .g files have the following mesh type: Standard mesh (Hex: 0x3A Dec: 58), and then the additional g1, g2, g3, files may have a textured mesh type (Hex: 0x3B Dec: 59). Anyway in this case 35660.g has (wrongly) a mesh type of 0x3B and also texture coordinates. While LDD will not complain about this, this is not according to Legos 'internal' standards.