75060 - Slave I
OMR Compliant
Missing:
- Minifig patterns documented in the file
- 2 Minifig accessories documented in the file
- Stickers. Oh so many stickers...
Comments: The angles on the side hull plating gave me fits so they are very close best fit.
Missing: Minifig Head, Torso, Hips, and Leg patterns as documented in the file
[color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif][color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif]Comments: None[/font][/size][/color][/font][/size][/color]
I've been doing some experiments and Roland suggested I shared them in this forum.
I've done some icons and themes in the past for LDCad. They are usually flat design themes, from several colors, with clear monochromatic icons
But I also wanted to be able to change the color of the titlebar of LDCad window from white, in the example above, to match the color of the menubar. I asked Roland about it but unfortunately that option was not available through the regular configuration files. But his reply about objects and windows class put me in the right track! I research a little and found out Autohotkey, a scripting language for Windows.
And what started as a pure cosmetic change turned out into a little addon that creates 4 extra buttons on the menubar, some additional hotkeys and the possibility to toggle on/off completely the window titlebar.
Here is a brief technical explanation. Autohotkey script grabs LDcad class window and creates an overlay GUI, an extension of the menubar, at a certain position. It creates the extra buttons and show/hides them as necessary. Then registers the mouse clicks and position to change images, cursor and run actions. Pressing the new menubar button will maximize the window, remove titlebar and show additional window control buttons on the menubar (min, restore, close window). It will also register new hotkeys to enable/disable the titlebar, show/hide the menubar, reload script, etc. The autohotkey script is called by a new autorun.lua script also included. So once LDCad loads and finishes updating the PartBin, you'll see a CMD window flash briefly (due to limitations of the io.popen function in the lua script) and the new button will appear on the menubar. Feel free to open the autohotkey script and look around.
Features:
1. New Hotkeys
- CTRL+T to toggle titlebar
- F11 to toggle menubar (have to config LDCad hotkey show/hide menubar to F10)
- Left Double Click on menubar will maximize/restore window
8099 - Midi-Scale Imperial Star Destroyer
OMR Compliant
Missing: Nothing
Comments: The hull plate angles are as close as they can be but there is still a small amount of part overlap.
As we are in the progress of amending the Sticker Specifications, what do you think of adding this one:
recently, LEGO started to print numbers next to their stickers to easier identify them, it looks like common sense to include this number as a letter in the part number, i.e. 01 -> "a", etc.
If there are more than 26 stickers on a sheet, they should be numbered as 27 -> aa, 28 -> ab
WOuld it make sense to add this and is it compatible with the library, i.e. was there enough common sense in the past to number the stickers accordingly since they introduced this scheme?
Is it possible to use a script to create a submodel in LDCad?
I ask this because I have to create multiple submodels that all require some basic other (LPub3D) metacommands and one or more parts, always in the same place.
This should be done by looping through a simple series of model names and descriptions.
I need to have submodels called A1, A2, A3, A4, .... A16
And B1, B2, B3 to B16 etc.
All the way to H.
Then I need submodels LA1, LA2, etc. to LH16
The A1, B1, etc. submodels should all have these lines:
Code:
0 ROTSTEP 90 180 0 ABS
0 !LPUB CALLOUT BEGIN
1 16 0 0 0 -0.5 0 0 0 0.5 0 0 0 -0.5 LA1.ldr
0 !LPUB CALLOUT END
0 !LPUB ASSEM MODEL_SCALE LOCAL 1.2500
0 !LPUB PLI BEGIN IGN
1 71 -150 0 150 1 0 0 0 1 0 0 0 1 91405.dat
0 !LPUB PLI END
Where in line 3 LA1.ldr is, of course, incremental like LA2, LA3, etc.
The LA1, LA2, etc. submodels should have more part lines in them and all start looking like this:
Code:
0 !LPUB ASSEM MODEL_SCALE LOCAL 0.3500
0 !LPUB PLI BEGIN IGN
[many part lines, all the same]
0 !LPUB PLI END
I was thinking about creating some sort of array that contains the names of the submodel files and then loop through to create all the submodels I need.
At least, that is my theory if I can use a script.
I have been working on the packaging of ldraw for the conda package manager (both ldraw-parts and ldraw-list) and I have come across a couple of pitfalls I wanted to report back - even though it is not completely a blocker for moving forward.
1. mklist
- The mklist package does not build out of the box. Everyone (FreeBSD, Debian, ArchLinux) appears to be applying the same patches to the makefile and sources so that it builds succesfully (and I had to do so as well). It may be worth including these patches upstream and bump the version of mklist which has not been updated in a while. If the package was hosted on GitHub or GitLab, it may be easier to submit patches back.
- The mklist source tarball is included in the parts zip file, including built artefacts for windows. Since it is a very simple program, I think that it is fine to provide a built executable on the website, although the parts library and mklist may be better separated.
- Quick note if anyone on this forum is involved in the debian packaging: the version number for the ldraw-mklist debian package appears to be the same as for parts library, while it should really be 1.6.
2. Persistent source tarballs for the parts library
It seems that with every update of the parts library, the new parts are uploaded in a separate zip file, while the complete.zip file is overwritten with the new version of the full library.
This may be an issue because old versions of complete.zip are not available anymore and we can't use a persistent URL for a given version. If you kept a complete-????.zip around for each release, we would be able to point to it persistently.
I am looking forward to hearing back, and super excited to work on the packaging of the lego CAD stack for conda!
I am working on some instructions that will use this part but in some other, custom, colors. Would it be possible to get this part re configured such that the panel is always trans clear and the color of the printing is the selectable color.
Quote:The sticker pattern is modelled in its true colours; they are not modifiable from the outside. All printed colours of the pattern must be matched, and the background (non-printed portion) of the pattern must use colour 16. Mimicking a colour by blending in the background colour of the part underneath using colour 16 is not allowed.
Change it to read:
Quote:The sticker pattern is modelled in its true colours; they are not modifiable from the outside. All colours of the top surface must be matched, and the back side and sides of the sticker must use colour 16. Print on a transparent plastic sticker sheet should use colour 16 on the transparent part of the top surface.
Currently, the following text exists in the sticker spec:
Quote:The sticker pattern is modelled in its true colours; they are not modifiable from the outside. All printed colours of the pattern must be matched, and the background (non-printed portion) of the pattern must use colour 16. Mimicking a colour by blending in the background colour of the part underneath using colour 16 is not allowed.
This proposal is to change the above text to instead read:
Quote:The sticker pattern is modelled in its true colours; they are not modifiable from the outside. All colours of the top surface must be matched, and the back side and sides of the sticker must use colour 16. Print on a transparent plastic sticker sheet should use colour 16 on the transparent part of the top surface.
![[Image: Blue-Theme.png]](https://i.ibb.co/8MkCK59/Blue-Theme.png)
![[Image: Dark-Theme.png]](https://i.ibb.co/Qk8NMMf/Dark-Theme.png)
