I checked the part 11439 and (personaly) think that have a bad shape, specialy in the named base 1 and 2 according to the official file. And taking as basis the shape in the Lego Builder app, decided to "fix" the problem. Also, I take the oportunity to do my first patterned part, in this case the one how corresponds to this part.
The files compossed of 7 subfiles: the first is the unpatterned part and the remaining six is for the patterned part.
If I need to submit my parts: may I use the number 11439 or 21548 (according to BL)? How I can number the patterned part (it's my first one) and the respective subfiles?
Hi! Has anyone started looking at the Stuntz ramps? I see they are requested a lot in the GBC community. I don't own them so I'm not able to look at them myself
I came across what I believe to the earliest extant example on the internet of Lego building instructions using an old (pre-Draw) language format. It's in a nearly 30-year-old Usenet message that can be seen here.
It builds a rabbit from the 1545 polybag set of 1992. I thought it would be fun to try and re-create the build using LDraw.
I have a snapshot of what I think it's supposed to look like, but I admit I wasn't able to get there from the instructions exactly. Maybe some of you will have better luck? If you try, I'd like to see what you come up with!
This year's topics:
* New police logo (italic "POLICE" with red underline), along with a large police station 6398 and a wide variety of police vehicles
* The 2nd wave of 9V train system, including the legendary club car 4547
Thanks for adding .svg as an allowed attachment type. Could we get .lua as well? Or is that a malware liability? (Feel like this may have been brought up before…)
Also, is there a full list posted somewhere, or maybe that could be a sticky post or something?
I have "completed" (read: not perfectly) my second attempt at an LDCad script. It's attached below (change .txt to .lua).
This script scans an LDraw file for parts or submodels that are hidden by buffer exchange in the final display state. If it finds any, it comments out their type 1 reference lines in the code, so that they won't appear in LDView, Studio, or other programs that don't recognize the BUFEXCHG metas. (For my inner monologue on the development process, see this thread.)
The script only runs from the end of the file (i.e., the last step) so it shows the completed model. It's not meant to work on intermediate steps to show the visibility at any given build phase. It's more meant as a cleanup tool
Some functionality is missing in this version, but hopefully I can improve it in the future:
It's not recursive, so you have to run the script separately on any submodels that also use buffer exchange, as well as on the main file. (This because I'm not sure how to access all the subfile objects of an mpd file via the API.)
It modifies the current file, rather than writing a new file, so you'd want to save the changed file as a copy. Offering a choice here would be a nice feature.
Technically, it's not actually a toggle function since it doesn't work in reverse—you can't un-comment hidden lines with this script. Mainly this is because there's no way to tell a commented-out ref line generated by this script from one that's meant to be there already. (I suppose I could add a flag of some kind to the lines affected by the script.) Meanwhile, you can always just use LDCad's undo.
Please feel free to send me any test files, particularly those with complicated or unusual implementations of buffer exchange, or to test your own models. (In particular, there may be an issue with Wine, causing a crash when closing open files in LDCad.)
This rule is already mostly enforced by the current PT but a few parts have slipped through the cracks and will be strictly enforced by the new software. Mismatch is a holdable error.
Edit: This is now enforced by the new part submission validation.
!HISTORY Lines
Excluding header edits by an admin (those will be covered separately), if you edit a file in any way, you must have a !HISTORY line in the file. This is required by CC BY 2.0/4.0 and is currently not enforced by the PT. Lack of !HISTORY is a holdable error.
Note: if you already have a !HISTORY line for the part's current release iteration, you don't have to create a new entry, just add to the existing entry.
P.s. This model is not buildable for real because some bricks are not available in the color the game uses.
Have some fun finding a colorscheme that can be build!
