It took me about ten years to realize that the 0 Name: entry is not used by any application. It is only there to identify the part and the licenses that it is under!
By reading the specs carefully for the 0 Name: entry I found in the Official Library Header Specification only the description that the 0 Name: entry is followed by the filename!
I doubt that 's\file.dat' or '48\file.dat' is a filename. It is a filename with relative path information.
For the '48' I can imagine that this is neccessary to address, as there might be a file with the same name in the 'p' folder. To know which of the files the current context is, it makes sense to add that ('48') information to the filename.
For the 's' the above mentioned is not correct, as subfiles needs to carry a 's' in the filename. So there cannot be any double file name. So my guess is that this is only added because we cannot avoid the '48' entry and by doing it this way all subdirectories of parts and p are addressed the same way.
But the above are mainly my thoughts (nothing is written about that) and so one main question still exists for me:
1) Why do we add the prefix to the filename? No application uses that line as it is not recommended in the File Format 1.0.2
2) Why does the Official Library Header Specification did not mention the use of the path prefix for 's' and '48'?
Given the importance of the MPD meta command, I think it would be good if, somewhere in the official specs, we stressed that support for the MPD meta command is highly recommended, and also note that the MPD meta command can be used in LDraw files with any file extension, not just in files with ".mpd" as the file extension.
- 100% GLKit.
- Updated to modern Objective-C syntax.
- Animate standard orientation changes.
- Support for ROTSTEP meta command.
- Fixed a bug where setting changes were propagated to the rendering of the in-step parts list rendering.
- Fixed a bug where the model browser wouldn't reload.
- 3039px41 --> Slope Brick 45 2 x 2 with Radar and Floppy Disk Slot Black Pattern
- 3039px57 --> Slope Brick 45 2 x 2 with Attitude Indicator and Flight Controls Pattern
- 3068bpx104 --> Tile 2 x 2 with Windows in Computer Screen Pattern
- 54090 --> Cockpit 8 x 16 x 2 Curved
- 54092cx1 --> Windscreen 8 x 16 with Smoke Glass and Blue Airline Bird Logo Pattern
- 54701cx1 --> Plane Fuselage Tail 12 x 16 x 7 with MdStone Bottom and Blue Stripes Pattern
I'm still working on the flexible part support in the next LDCad version, the system is setup in such away you can use pretty much any existing LDraw file as a donor (e.g. pneumatic segment etc).
But there are many flexible parts that don't have suitable donor parts in the existing official library. To supply non expert users with an easy to use 'out of the box' flexible part library I will need to create a collection of additional donor files.
So I was hoping if there's someone interested in helping me create these files. Some are easy like the 'technic axle flexible' those are pretty much just subsections of e.g. 32199.dat (caps and two different segments).
Others need some more thought like suitable segments for 'hose flexible', the existing ones in the official library are only useable for 'reference' placement like LSynth does.
I'm also thinking about supporting very weird things like bendable technic bricks (a real 16x1 brick can easily be bend 1 or 2mm), supporting this would only require a 'technic brick segment'.
There are more needed donors I'm sure, I haven't made an exact list yet. Such a list will come together on it's own when I start creating templates for all bendable stuff. If someone has such a (bendable parts) list (or want to compile one) that would be very helpful too.
So if anyone is interested please respond here or email me directly (address is on melkert.net/ldcad )
When converting quads + lines into rect primitives, Rectifier sometimes provided values near but not equal to 1. I delved into my code and soon found a bug causing this behaviour... then found an even better method that provides tidier and more compact LDraw code.
In this example, LDraw code was shrunk at 37% with 1.8, it's now only 29%.
Note that there was nothing wrong with 1.8 result, as inlining back both versions gives exactly the same lines and quads.
Hej,
I really hope, that the parts will leave the PT soon. But first I have a question.
Should I create a shortcut for the top part with the connector attached (all in all 4 shortcuts due to the red or black inside version) and shortcuts for top and bottom, which use the top-shortcuts and the bottom files (again 4 files) OR should I do only 4 top-bottom shortcuts with connectors.
I prefer the first point, because it's easier to handle for the users, but it feels a bit like spamming the PT for me.
