Oh, that sounds like a Good Idea ™ to me.
Keeping the "stu2" MOVED-TO's for a while (until MLCad has been updated........) would be tolerable for me.
Especially, putting the low-res stud variants into a dedicated folder
opens the way for ANALOGOUSLY treating their HI-RES variants:
JC Tchang has created a bunch of VERY NICE, VERY HIGH-RES studs,
which of course are somewhat redundant to LDViews internal stud replacement,
but they allow to use ultra high res studs also in other tools. They are here:
http://jc-tchang.philohome.com/manuel/pa...ogo_tchang
His current solution is, for switching between the studs resolutions,
to invoke a batch which replaces stud.dat etc.
I would better like to have his files included with the library normally as primitives,
and as hi-res-replacements for the normal studs, analogously to their low-res replacements "stu2*".
This additionally would solve ANOTHER of our currently pending problems: see
http://www.ldraw.org/cgi-bin/ptdetail.cg.../3334h.dat
There, duplicates of our parts have been created, just to have better, hi-res underside studs.
This is a bad idea ™. Instead, we should analogously to the hi-res/low-res top studs,
offer hi-res/low-res underside studs, and applications should be enabled to switch between them
at runtime.
Keeping the "stu2" MOVED-TO's for a while (until MLCad has been updated........) would be tolerable for me.
Especially, putting the low-res stud variants into a dedicated folder
opens the way for ANALOGOUSLY treating their HI-RES variants:
JC Tchang has created a bunch of VERY NICE, VERY HIGH-RES studs,
which of course are somewhat redundant to LDViews internal stud replacement,
but they allow to use ultra high res studs also in other tools. They are here:
http://jc-tchang.philohome.com/manuel/pa...ogo_tchang
His current solution is, for switching between the studs resolutions,
to invoke a batch which replaces stud.dat etc.
I would better like to have his files included with the library normally as primitives,
and as hi-res-replacements for the normal studs, analogously to their low-res replacements "stu2*".
This additionally would solve ANOTHER of our currently pending problems: see
http://www.ldraw.org/cgi-bin/ptdetail.cg.../3334h.dat
There, duplicates of our parts have been created, just to have better, hi-res underside studs.
This is a bad idea ™. Instead, we should analogously to the hi-res/low-res top studs,
offer hi-res/low-res underside studs, and applications should be enabled to switch between them
at runtime.