Relatively recent yes, when I created the animal "segment" patterns (such as https://www.ldraw.org/parts/official-par...d=31111p02). There was already a patterned version, but it was not subparted (https://www.ldraw.org/parts/official-par...d=31111p01)
LDCad Part Snapping missing/errors
I've processed up to message #48
And I also added a new bunch of files by Alex Taylor (incl some unofficial ones)
As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf
And I also added a new bunch of files by Alex Taylor (incl some unofficial ones)
As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf
(2020-08-04, 20:42)Roland Melkert Wrote: I've processed up to message #48
And I also added a new bunch of files by Alex Taylor (incl some unofficial ones)
As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf
I'm a little unclear how the shadow.sf file in the seeds directory relates to the shadow libraries in Application Data. How do the newly added parts get into the official library, and what if I'm using a custom library, containing all the official content but also whatever new files I've added?
Just want to be sure I'm not updating the hard way. :-)
(2020-08-05, 23:06)N. W. Perry Wrote: I'm a little unclear how the shadow.sf file in the seeds directory relates to the shadow libraries in Application Data. How do the newly added parts get into the official library, and what if I'm using a custom library, containing all the official content but also whatever new files I've added?
The contents of .sf (plain zip) files are synchronized with the per user location at program start.
This way each user can setup their own bins and options etc, while still having defaults out of the box.
It will only update existing files and remove obsolete ones, if you got additional custom content that will not change.
If you are using an unpacked shadow it shouldn't affect you at all, unless you unpack the updated shadow (.csl) in the user location again.
(2020-08-06, 20:20)Roland Melkert Wrote: The contents of .sf (plain zip) files are synchronized with the per user location at program start.
This way each user can setup their own bins and options etc, while still having defaults out of the box.
It will only update existing files and remove obsolete ones, if you got additional custom content that will not change.
If you are using an unpacked shadow it shouldn't affect you at all, unless you unpack the updated shadow (.csl) in the user location again.
What I've been doing is copy the offLib.csl to my own custLib.csl, then I unpack that and use it as my shadow library so I can save corrections and new shadow files.
So if I understand correctly, my process should be:
- -Before installing the new .sf, I should re-pack my custom library to custLib.csl
- -Set custLib.csl as my library so that it will synchronize
- -Install the new .sf and re-launch LDCad
- -Re-unpack custLib and switch to that directory when I want to make more changes
(2020-08-07, 0:30)N. W. Perry Wrote: What I've been doing is copy the offLib.csl to my own custLib.csl, then I unpack that and use it as my shadow library so I can save corrections and new shadow files.
So if I understand correctly, my process should be:
I should now have all updated files, plus whatever new ones I'd made (unless they were corrections to existing files, which are now replaced with your updates). Right?
- -Before installing the new .sf, I should re-pack my custom library to custLib.csl
- -Set custLib.csl as my library so that it will synchronize
- -Install the new .sf and re-launch LDCad
- -Re-unpack custLib and switch to that directory when I want to make more changes
No. You'll destroy your customizations if you do that. You have have more that one shadow library. Better to have a separate shadow library that only contains your altered/added files much like is done with unofficlal parts. Then your custom lib will override the "official" Roland supplied one.
(2020-08-07, 0:55)Orion Pobursky Wrote: No. You'll destroy your customizations if you do that. You have have more that one shadow library. Better to have a separate shadow library that only contains your altered/added files much like is done with unofficlal parts. Then your custom lib will override the "official" Roland supplied one.
But I actually want the Roland-file to override mine, that's OK. I only want to keep any of my additional files that haven't made it into the "official" package yet. It sounded like those wouldn't get overwritten.
For unofficial parts it's no problem; the shadow info can even be baked into the main file. For official parts, you can only choose one shadow library per search path, but I suppose I can duplicate the official search path (same main folder, but different shadow libs). Keep the offLib as a zipped library, and use an unpacked one for saving my own additions/corrections. Would that work?
(2020-08-07, 2:52)N. W. Perry Wrote: But I actually want the Roland-file to override mine, that's OK. I only want to keep any of my additional files that haven't made it into the "official" package yet. It sounded like those wouldn't get overwritten.
For unofficial parts it's no problem; the shadow info can even be baked into the main file. For official parts, you can only choose one shadow library per search path, but I suppose I can duplicate the official search path (same main folder, but different shadow libs). Keep the offLib as a zipped library, and use an unpacked one for saving my own additions/corrections. Would that work?
The .sf will sync offLibShadow.csl as a whole.
So you'll need to unpack it (again) yourself. I sugest first renaming the original unpacked folder so you can visualize changes with e.g. winmerge.
Each search location has only one shadow as the content will be appended to the pure part files before parsing start.
(2020-08-07, 17:19)Roland Melkert Wrote: The .sf will sync offLibShadow.csl as a whole.
So you'll need to unpack it (again) yourself. I sugest first renaming the original unpacked folder so you can visualize changes with e.g. winmerge.
Each search location has only one shadow as the content will be appended to the pure part files before parsing start.
Got it. So I'm already doing it correctly (re-naming and re-unpacking the synced official library). The difficulty is just that MacOS doesn't have a convenient way to merge folders if they contain sub-folders, so I have to do that part manually.
The big plastic wheels need cylinder snaps:
6118.dat
2593.dat
2515a.dat and 2515b.dat
6118.dat
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 16 R 8 42] [pos=0 0 8] [ori=1 0 0 0 0 -1 0 1 0]
2593.dat
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 16 R 8 4] [pos=0 0 -2] [ori=1 0 0 0 0 -1 0 1 0]
2515a.dat and 2515b.dat
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 16 R 8 6] [pos=0 0 -2] [ori=1 0 0 0 0 -1 0 1 0]
RE: Part Snapping missing/errors
2020-10-06, 14:21 (This post was last modified: 2020-10-06, 14:27 by Stefan Frenz. Edit Reason: adde 2476a )
2020-10-06, 14:21 (This post was last modified: 2020-10-06, 14:27 by Stefan Frenz. Edit Reason: adde 2476a )
Staircase Spiral Axle (40244) does not snap into Tile 2x2 with Pin (2460) nor into Plate 2x2 with Pin (2476a)
Bug-eye 30208.dat needs a grid of studs and a big 40R cylinder:
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 6 4] [grid=C 4 C 4 20 20]
0 !LDCAD SNAP_CYL [gender=M] [caps=one] [secs=R 40 4] [pos=0 -4 0] [ori=1 0 0 0 -1 0 0 0 -1]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 38 4] [pos=0 -4 0] [ori=1 0 0 0 -1 0 0 0 -1]
RE: Part Snapping missing/errors
2020-11-30, 19:11 (This post was last modified: 2021-03-05, 13:12 by Jaco van der Molen.)
2020-11-30, 19:11 (This post was last modified: 2021-03-05, 13:12 by Jaco van der Molen.)
Wheel spoked 4489b needs to snap to 4488 (plate 2x2 with pin) for example.
I believe this will do the trick
0 !LDCAD SNAP_CYL [group=wpAxHole] [gender=F] [caps=one] [secs=A 4 10 R 5 2] [pos=0 0 8] [ori=1 0 0 0 0 -1 0 1 0]
I believe this will do the trick
0 !LDCAD SNAP_CYL [group=wpAxHole] [gender=F] [caps=one] [secs=A 4 10 R 5 2] [pos=0 0 8] [ori=1 0 0 0 0 -1 0 1 0]
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
RE: Part Snapping missing/errors
2020-11-30, 19:18 (This post was last modified: 2021-03-05, 13:04 by Jaco van der Molen.)
2020-11-30, 19:18 (This post was last modified: 2021-03-05, 13:04 by Jaco van der Molen.)
Minifig Flame/Plume triple 64647 should also snap at the small bar piece to snap to parts with clips (like 60475b Brick 1x1 with clip vertical Thick C-clip)
0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 4 6] [center=true] [slide=true] [pos=0 -3 0]
0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 4 6] [center=true] [slide=true] [pos=0 -3 0]
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
RE: Part Snapping missing/errors
2021-03-05, 7:09 (This post was last modified: 2021-03-05, 13:02 by Jaco van der Molen.)
2021-03-05, 7:09 (This post was last modified: 2021-03-05, 13:02 by Jaco van der Molen.)
Brick 1x2x5 without inner ridges (46212a) does not have snap info at the bottom, only the studs on top.
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 20] [pos=0 120 0] [grid=C 2 1 20 0]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 20] [pos=0 120 0] [grid=C 2 1 20 0]
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
RE: Part Snapping missing/errors
2021-03-05, 12:59 (This post was last modified: 2021-03-05, 13:00 by Jaco van der Molen.)
2021-03-05, 12:59 (This post was last modified: 2021-03-05, 13:00 by Jaco van der Molen.)
Part 4739 Treasure Chest Lid should have snap info for the studs too.
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=30 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=10 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=-10 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=-30 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=30 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=10 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=-10 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=-30 0 0]
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
(2020-11-30, 19:16)Jaco van der Molen Wrote: Plate 1x2 with thick C-clip 63868 only snaps to the left and right side bar pieces of 2540 Plate 1x2 handle.
Should also snap to the center bar.
This seems to be fixed, although it can be a little tough to fit it to the middle bar since the outer parts seem to win it from the middle snap info.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
I've processed all up to msg #75
I also added lots of info for the 20-01 library (I'm behind 3 libraries now )
As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf
I fixed the snap info but due to a bug in the snapping solver it won't snap correct, this will be fixed in 1.7 Alpha 1.
I also added lots of info for the 20-01 library (I'm behind 3 libraries now )
As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf
(2020-11-30, 19:18)Jaco van der Molen Wrote: Minifig Flame/Plume triple 64647 should also snap at the small bar piece to snap to parts with clips (like 60475b Brick 1x1 with clip vertical Thick C-clip)
I fixed the snap info but due to a bug in the snapping solver it won't snap correct, this will be fixed in 1.7 Alpha 1.
(2021-03-06, 22:37)Roland Melkert Wrote: I've processed all up to msg #75
I also added lots of info for the 20-01 library (I'm behind 3 libraries now )
As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf
I fixed the snap info but due to a bug in the snapping solver it won't snap correct, this will be fixed in 1.7 Alpha 1.
Great! Looking forward to 1.7 Alpha 1 ;-)
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
(2021-05-20, 10:49)Jaco van der Molen Wrote: I think you can copy the info from 62712 to both 57910 and 92013?
I added:
Code:
0 !LDCAD SNAP_CLEAR [ID=axle]
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 8 A 6 16] [pos=0 24 0]
0 !LDCAD MIRROR_INFO [baseFlip=Z] [counterPart=self]
to all three, and variations of:
Code:
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 5] [pos=40 10 11.5] [ori=1 0 0 0 0 1 0 -1 0]
0 !LDCAD SNAP_GEN [group=techBallJnt] [gender=F] [bounding=sph 12.7] [match=size] [placement=free] [pos=40 10 0] [mirror=none]
The half socket subparts.
(2021-05-20, 20:00)Roland Melkert Wrote: I added:
Code:0 !LDCAD SNAP_CLEAR [ID=axle]
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 8 A 6 16] [pos=0 24 0]
0 !LDCAD MIRROR_INFO [baseFlip=Z] [counterPart=self]
to all three, and variations of:
Code:0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 5] [pos=40 10 11.5] [ori=1 0 0 0 0 1 0 -1 0]
0 !LDCAD SNAP_GEN [group=techBallJnt] [gender=F] [bounding=sph 12.7] [match=size] [placement=free] [pos=40 10 0] [mirror=none]
The half socket subparts.
Thanks!
Is the shadow updated?
http://www.melkert.net/action/download/shadow.sf
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl
RE: Part Snapping missing/errors
2021-09-30, 17:26 (This post was last modified: 2021-09-30, 17:43 by Roland Melkert.)
2021-09-30, 17:26 (This post was last modified: 2021-09-30, 17:43 by Roland Melkert.)
(2021-09-30, 3:28)N. W. Perry Wrote: Wheel rim 2998 does not snap correctly to wheel hub 2999. It ends up rotated 90° from where it should be.
This is one of those parts I haven't seen in real life (didn't even realize the pairing), so I took a guess on it.
How should 2999 be positioned with a 2998 at 0,0,0?
edit, I think this should work:
2999a.dat
Code:
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 32] [pos=0 0 9] [ori=0 -0 -1 1 -0 0 -0 -1 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 32] [pos=0 0 -9] [ori=-0 -0 1 1 -0 0 0 1 0]
2998.dat
Code:
0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3 R 20 4 R 18 56 _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 -0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 32] [pos=0 1 0]
The numbers are mixed up…but this is what works for me:
2998a.dat
Position should stay at 0 0 0, and there doesn't seem to be a need for the second snap. This wheel only seems to fit one way.
2999.dat
This is fine with the pos adjusted to 0 11 0. (The original was 0 12 0 and was off by 1 LDU.)
2998a.dat
Code:
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 23] [ori=0 0 -1 1 0 0 0 -1 0]
Position should stay at 0 0 0, and there doesn't seem to be a need for the second snap. This wheel only seems to fit one way.
2999.dat
Code:
0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3 R 20 4 R 18 56 _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 23] [pos=0 11 0]
This is fine with the pos adjusted to 0 11 0. (The original was 0 12 0 and was off by 1 LDU.)
(2021-10-01, 2:05)N. W. Perry Wrote: The numbers are mixed up…but this is what works for me:
2998a.dat
Code:0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 23] [ori=0 0 -1 1 0 0 0 -1 0]
Position should stay at 0 0 0, and there doesn't seem to be a need for the second snap. This wheel only seems to fit one way.
2999.dat
Code:0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3 R 20 4 R 18 56 _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 23] [pos=0 11 0]
This is fine with the pos adjusted to 0 11 0. (The original was 0 12 0 and was off by 1 LDU.)
The hub is free movable in the arm without the wheel. But it should snap to its final position in LDCad, I think.
The wheel can be connected in one way only. It's not possible to connect it with the backside turned to the outside.
(2021-10-01, 7:54)Max Martin Richter Wrote: The hub is free movable in the arm without the wheel. But it should snap to its final position in LDCad, I think.
The wheel can be connected in one way only. It's not possible to connect it with the backside turned to the outside.
The arm is 6540a/b, by the way. I did check the fit of all three parts, and with the 0 11 0 position on the wheel rim, everything lines up snugly.
(2021-10-01, 15:24)Magnus Forsberg Wrote: Is it possible, and maybe even wanted, to have 2907 snap to the inside of the hub 2999 ?
Good question…I am not fortunate enough to have owned the set these parts came in (but can you guess what I've been building?). But while 2907 is meant to rotate on XZ along with 2999, it is also meant to pivot independently on XY. So perhaps snapping is not recommended?
(2021-10-01, 17:10)N. W. Perry Wrote: Good question…I am not fortunate enough to have owned the set these parts came in (but can you guess what I've been building?). But while 2907 is meant to rotate on XZ along with 2999, it is also meant to pivot independently on XY. So perhaps snapping is not recommended?I think it can snap: this is the same kind of joint type as 32494/92906.
(2021-10-01, 17:10)N. W. Perry Wrote: Good question…I am not fortunate enough to have owned the set these parts came in (but can you guess what I've been building?). But while 2907 is meant to rotate on XZ along with 2999, it is also meant to pivot independently on XY. So perhaps snapping is not recommended?
Seems logical, acting like a compact universal joint like in real cars.
RE: Part Snapping missing/errors
2021-10-01, 19:21 (This post was last modified: 2021-10-01, 19:21 by Roland Melkert.)
2021-10-01, 19:21 (This post was last modified: 2021-10-01, 19:21 by Roland Melkert.)
(2021-10-01, 18:46)N. W. Perry Wrote: Will the snapping data depend on the orientation of the grooves (as was recently corrected in the PT)?
It could if it uses a generic sphere meta using absolute placement.
That would get it in a good starting position, so the user can slide it inside and rotate/bend the attached axle later on.
Like so (including the corrections reported above)
2999.dat
Code:
0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3 R 20 4 R 18 56 _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 32] [pos=0 2 0]
Code:
0 !LDCAD SNAP_GEN [gender=M] [bounding=sph 15] [ori=0.92388 0 0.382683 0 1 0 -0.382683 0 0.92388]
2998a.dat
Code:
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 32] [pos=0 0 9] [ori=0 0 -1 1 0 0 0 -1 0]
optimally it would need a new snap connection (sphere in a tube), but I'm not sure it would really be that more helpful.
« Next Oldest | Next Newest »
Users browsing this thread: 63 Guest(s)