JBrickBuilder connection model

[Philippe Hurbain]

I agree that these parts should be fixed. We already cleaned a lot of parts that used stud primitives for capped cylinders, but a few old parts still use similar (bad) tricks.

- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.

Clearly we need to define an inside-out version of axlehol8.dat to fix these parts.

- part 4727.dat uses a "peghole.dat" as a base. I don't know, but should be better use a stud4.dat, I think. If you use this part with autodetect, a "peghole" connection is placed in a totally wrong position
- part 3680.dat: an inverted peghole.dat to obtain central hub.
- 32556.dat: an inverted peghole.dat to obtain the flange.
just to say some.

All these parts are easy to fix, but these situations are not easy to detect visually. I think we should create a special thread to report these abuses.

So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.
That's why SR3D and LDCad (http://forums.ldraw.org/showthread.php?t...0#pid15510) offer a mechanism to clear auto-detected connectivity. But I much prefer some wrong additional connection to missing ones

Scaled studs at another example of what I would consider primitive misuse.

I don't think this is an issue connectivity wise... Or is it ?