I've realised that there's a few parts that are held up by only minor changes suggested by reviewers. Since we're often open to re-editing by secondary authors link to any of these here and hopefully someone whose vote won't be lost can do something about it. eg. stud41fw.

I've noticed others in the past and made the edits but this way we can keep track of more.

Tim

PS. I'm not sure if this should remain sticky but I think for now it can be.

the original submitter of the part does not track which comments it received,
and is not working on applying the suggested corrections.

This way, the suggestions stay there forever; they prevent a CERT but are not worth a HOLD.
Result: the part rots away on the Parts Tracker.

Sometimes, after a long time, I cannot resist and fix such things myself to bring things forward,
but I think we should extend the current policy that a part may get altered by others if the original
author does not respond within some time. Currently, that changing is only "allowed" when the part has a HOLD.
That's too un-progressive IMHO. We should extend that to any correction suggestion.

Nice to hear that, I've the same perspective; to me, the PT should be somewhat of a collaborative workbench.
In many cases in the past, I was tempted to directly fix problems instead of voting hold:
The latter only slowed down the process: Instead of having a fixed part which could get certified,
you got a held part which sat there then. Well, however, I've in the past 8 years also received
feedback that some authors want to completely author their parts on their own while on the PT,
and I got criticized for editing their files.
So I know from some people that they are fine with it, and I then sometimes just do the correction,
do speed up things. However, it gets complicated, when the solution suggestion I have in mind
might not be what the majority wants. I try to restrict myself then and not do the change.
This way: good that we have this forum.

Since this post is called 'Existing Part Edit Requests' I thought this would be the right place for this:

Some little error with 4600.dat : as this file got offical (the updated version) again with the last part update te description is wrong: it is now named 'Plate 2 x 2 with Wheel Holder'what is the same as 4488.dat . First this description should be 'Plate 2 x 2 with Wheel Holders' (as it was as teh part was unofficial) and secend I presume to diffrent parts shouldn't have the same description.

Another part what need a chance is 2559.dat there a four open studs missing. Compare the part to this

Since I'm not a part author (and to became one for so minor changes, I don't think is teh right thing), I want to point out two colour changes on to parts. These parts are 3846p44.dat and 973p44.dat (wolf pack shield and torso. The coat of arms boundaries should be red/dark red (I prefer dark red, because it's closer to the real part, but the real part has the main colour brown so the red print looks like dark red). Right now the boundaries are yellowish green since the colour code of 326 is that colour- I don't know for what this code (326) was for when this part was created but now its the wrong colour.
Another thing is that these part still use 383 (chrome silver) instead of 179 (flat silver) (or was it another silver which should be used for patterns?).

There is again a part with hollow studs which seems to have a closed stud version or is wrong made with the hollow studs:2582.dat Hinge Panel 2 x 4 x 3 & 1/3
The pictures of the '90 space shuttle instructions indicated that the closed studs version exists :1682 Space Shuttle Instructions

Thanks for sharing your thoughts.
I have had a quick look at Bricklink, but there is also no variant listed.
The only more information I got there is that this is same in mould than http://www.bricklink.com/catalogItem.asp?P=32125
So if there are variants for 2712 I think there are also variants for 32125.

Not sure if this is the correct place to post but I noticed there is something weird going on with the minifig legs (3816 and it's mirror or one of its subs).

There seem to be overlapping polys at the top backside. You can see by enabling wireframe in LDView. The part also suffers from rounding errors (like we talked about in some of the recent smoothing threads) in the same area.

The same set-up in real parts makes it clear that the current 3816s01.dat is really wrong.
It is possible to place this mock up on a 3023 in real parts, but not in ldraw-parts

1 44 60 40 0 1 0 0 0 1 0 0 0 1 3023.dat

3.)
A sitting minifig should have his back ~2 ldu moved forward and 4 ldu down.
Maybe the cylindrical section of the leg should be a little bit larger (green cyli),
to give the backside a more vertical surface, if the foot is moved.

4.)
Apart from the mentioned errors we also need to create a new leg-subfile without the side surface.
Many of the Collector minifigs have a pattern printed of the side of the leg.

Is there a good explanation for this error?
How do we solve it?
Do we need to recreate all patterned hips and legs?

If we decide to correct this error, I am sure we need to update all leg parts. The hips should not be affected I think and therefore the combinations hips/legs should also be fine just after updating the leg parts. For this task LDStructure should be of good help for us.

Since the variant with no side pattern, and the variant with a side pattern are both common, perhaps it makes sense to use the unpatterned one as the existing subfile, and the new patterned one as a new subfile (obviously the former uses the latter). That way only the basics need redoing, and the existing leg parts can stay as is.

Random thoughts about this issue:
- Tim's suggestion seems good, especially since - AFAIK - there is no legs with side pattern in LDraw library yet.
- Care must be taken not to utterly break models in the field using present leg.
- About patterns: hopefully it should be possible to keep existing patterns, using a relatively simple transformation?
but....
IMHO, the best solution would be to let existing legs / patterned legs as-is (after all they worked for years and nobody complained!!!), and create a brand new leg model (3816b or so) with all these issues corrected.

It would be good if you could - thanks. I think they would still need to go through a full Parts Tracker review, but once the base parts are approved, the patterned versions should be straightforward to review.

Is there any reason you are suggesting a 'b' suffix? We haven't used 'a' yet.

Duplication is neccessary to maintain backwards compatibility and to avoid breaking existing models. We must maintain official parts with their existing origin and orientation. Making them obsolete discourages them from being used in the future, so long as tools honour the ~ prefix.

Hi, I have a beginner question on what is the best way how to create a variant of an existing part.
There is a part 3684.dat that has hollow studs in the LDraw library. I want to create a version with solid studs that is missing - 3864c Slope 75 2 x 2 x 3 - Solid Studs.
The model with studs is stored in s\3684s01.dat. So my plan is to move the geometry to a new file s\3684s02.dat and in the s\3684s01.dat leave only hollow studs and link to s\3684s02.dat. This way I can share the geometry with the new part with solid studs and it will not break patterned parts. Is it correct approach?
Or should I just create a copy of the complete geometry and do not edit the existing part?

(2016-12-26, 20:32)Tomas Kralicek Wrote: Is it correct approach?
Or should I just create a copy of the complete geometry and do not edit the existing part?

Yes, please re-use as much as possible in a second subfile.
I had a look into the design. It has some issues and needs a rework. Incorrect edges and overlapping primitives.

I fixed overlapping primitives and used more primitives in the existing file.

Now to the update. I was looking for similar case in the LDraw library and found part 4864. It has version with solid and hollow studs. But it uses different approach then I was planning. Studs are placed into the main file and the subfile is shared between both of them. I was planning to make two subfiles one with solid and one with hollow studs that will share another subfile (3684s02).
Should I be consistent with the 4864 part? If so I will also need to update the existing 3684 and 3684p22.

>I was planning to make two subfiles one with solid and one with hollow studs that will share another subfile (3684s02).

That IMHO would be too complicated.
The studs are in the main file usually to prevent that they get a mirrored logo.
The usual approach is to put the symmetric portion of a part into a subfile,
and then use that one both from the solid and hollow stud version.
The solid stud version then again adds its studs in its main file,
and the hollow stud version adds its studs in its main file.

We might need another solution here, since we also have to deal with a, b and c versions of this part.

I suggest changing s01 into a common file, without studs, front and back surface. Or is that what you're suggesting?

3684 has to become a Moved to 3684a
3684p22 should be Moved to 3684ap22

3684a should use s01 and add hollow studs and surfaces ( part alias: 30499 )
3684b should also use s01 and add hollow studs and surfaces
3684c should use s01 and add solid studs and surfaces ( part alias: 98560 )

Why is b-version called "Smooth" ? What makes it different from the a-version?

I have updated existing parts 3684 and 3684p22 and renamed them to 3684a. And what is the correct process to submit them now? As these will be new names I will be able to submit them to tracker immediately. And to make the original 3684 become Moved ...,is it enough to email a request to parts<at>ldraw.org?

I know this is an older thread but I think my concern fits very well to it's title.

I came across that the two torus primitives "t04ounit.dat" (as an outer regular torus primitive) and the reverse ratio torus primitive "r04o1000.dat" are essentially identical.
Also a major radius to tube radius of 1:1 couldn't exactly be called reverse. So in my opinion the "r04o1000.dat" would actually be redundant and therefore obsolete.

I investigated further, that the "r04o1000.dat" is only used in 2 official parts ("6797.dat" and "56554.dat") and 1 official subpart ("11459s01.dat") and apart from that also in 1 unofficial part ("34172.dat") and 2 more unofficial subparts ("2715s01.dat" and "34172s01.dat"). That's all up to now with regard to the latest (un)official LDraw parts collections (http://www.ldraw.org/library/updates/complete.zip and http://www.ldraw.org/library/unofficial/ldrawunf.zip).
So there are all in all only six available files where this part is actually used and where the "r04o1000.dat" could just be replaced by "t04ounit.dat" and I litterally mean just a word find-and-replace is enough and everything is fine and we can get rid of this unnecessary part.

What do you think?

I mean I could do that in a wink if you want but I'd like to avoid a new and absolutely unnecessary recertification process for these few affected parts.
And a new certify process would be obsolete because it wouldn't actually affect these parts in any way as these replaced primitives are really absolute identical.

I know this is an older thread but I think my concern fits very well to it's title.

I came across that the two torus primitives "t04ounit.dat" (as an outer regular torus primitive) and the reverse ratio torus primitive "r04o1000.dat" are essentially identical.
Also a major radius to tube radius of 1:1 couldn't exactly be called reverse. So in my opinion the "r04o1000.dat" would actually be redundant and therefore obsolete.

I investigated further, that the "r04o1000.dat" is only used in 2 official parts ("6797.dat" and "56554.dat") and 1 official subpart ("11459s01.dat") and apart from that also in 1 unofficial part ("34172.dat") and 2 more unofficial subparts ("2715s01.dat" and "34172s01.dat"). That's all up to now with regard to the latest (un)official LDraw parts collections (http://www.ldraw.org/library/updates/complete.zip and http://www.ldraw.org/library/unofficial/ldrawunf.zip).
So there are all in all only six available files where this part is actually used and where the "r04o1000.dat" could just be replaced by "t04ounit.dat" and I litterally mean just a word find-and-replace is enough and everything is fine and we can get rid of this unnecessary part.

What do you think?

I mean I could do that in a wink if you want but I'd like to avoid a new and absolutely unnecessary recertification process for these few affected parts.
And a new certify process would be obsolete because it wouldn't actually affect these parts in any way as these replaced primitives are really absolute identical.

Kind regards,
Tom

Thanks for pointing this out. Revised files are now on the Parts Tracker replacing r04o1000 with t04ounit. However trivial the change to content I'd prefer them to go thorugh the certification process, but hopefully this can be quick. I have also removed r04o1000 from the primitives reference webpage.

(2018-03-25, 11:53)Magnus Forsberg Wrote: Primitive substitution (in LDView) doesn't seem to work on t04ounit.dat, but it worked on r04o1000.dat

Thomas's post on Wednesday was the first I've heard for t04ounit.dat, so no, it's not something I have supported in LDView. It's also unclear to me why "unit" was chosen; I would argue that unless there is some pressing reason, it should instead be 1000.

(2018-03-25, 11:53)Magnus Forsberg Wrote: Primitive substitution (in LDView) doesn't seem to work on t04ounit.dat, but it worked on r04o1000.dat

Thomas's post on Wednesday was the first I've heard for t04ounit.dat, so no, it's not something I have supported in LDView. It's also unclear to me why "unit" was chosen; I would argue that unless there is some pressing reason, it should instead be 1000.

This has been in the primitives reference for some time and was discussed at length when introduced in 2005.

Quote:For regular tori, the last four characters of the file name rrrr denote the torus minor radius in LDu (1333=0.1333, 3333=0.3333), with the special designation 'unit' unsed to indicate a radius of 1.0000.

Your suggestion of using t04o1000 does not work, because this represents a torus with a minor radius of 0.1000.

In contrast:

Quote:For reverse ratio tori named like rfforrrr.dat, the last four characters of the file name rrrr represent torus minor radius with an implied decimal point after the first digit (1500=1.5, 4600=4.6).

With this information it makes more sense to reverse the changes I made keeping r04o1000 and obsoleting t04ounit. To avoid accidental usage of t04ounit, which would cause problems with primitive substitution, I believe this file should be a reference to empty.dat, NOT a '~Moved to' alias to r04o1000.

(2018-03-26, 8:13)Chris Dee Wrote: With this information it makes more sense to reverse the changes I made keeping r04o1000 and obsoleting t04ounit. To avoid accidental usage of t04ounit, which would cause problems with primitive substitution, I believe this file should be a reference to empty.dat, NOT a '~Moved to' alias to r04o1000.

I like r04o1000 over t04ounit because it doesn't require the special "unit" exception to the naming scheme. Though I don't understand what problems we would get with primitive substitution. Worrying about accidental usage of moved-to files is IMO unwarranted because we're already quite strict against using such files and most parts authoring programs (including Datheader, IIRC) complain about the use of them. We don't see new files being submitted that use "ring4.dat" for instance. And if someone accidentally used such an obsolete file, an invisible result wouldn't really solve the problem IMO, only create another footgun.

(2018-03-26, 8:13)Chris Dee Wrote: With this information it makes more sense to reverse the changes I made keeping r04o1000 and obsoleting t04ounit. To avoid accidental usage of t04ounit, which would cause problems with primitive substitution, I believe this file should be a reference to empty.dat, NOT a '~Moved to' alias to r04o1000.

I like r04o1000 over t04ounit because it doesn't require the special "unit" exception to the naming scheme. Though I don't understand what problems we would get with primitive substitution. Worrying about accidental usage of moved-to files is IMO unwarranted because we're already quite strict against using such files and most parts authoring programs (including Datheader, IIRC) complain about the use of them. We don't see new files being submitted that use "ring4.dat" for instance. And if someone accidentally used such an obsolete file, an invisible result wouldn't really solve the problem IMO, only create another footgun.

OK - I have reversed the changes and made t04ounit a ~Moved to for r04o1000. I'll recycle the 11 official files that currently use t04ounit.

I couldn't find "t08qunit.dat" at all in my LDraw folders and/or files but "t04qunit.dat" (from Unofficial\p\) is used in "85543c02.dat" (8x), "85543c03.dat" (4x) and "u9228c03.dat" (2x) all from "Unofficial\parts\".

Part 10p04.dat is a little wrong. The white dots of the house have to be moved 1 stud to the right. As you can see they're current 8 studs from the side of the baseplate, but it should be 9 studs as can be seen here and here.

(2018-09-03, 15:11)Merlijn Wissink Wrote: Part 10p04.dat is a little wrong. The white dots of the house have to be moved 1 stud to the right. As you can see they're current 8 studs from the side of the baseplate, but it should be 9 studs as can be seen here and here.

Please send the corrected version to parts@ldraw.org and I will do a proxy submit under your name.

(2018-09-14, 16:36)Gerald Lasser Wrote: Is there another hand somewhere in the Lib with the correct spacing?

It doesn't seem. I don't think that correcting the shape of the hand would cause any problem in existing models if we keep exact position connexion points. "Fingers" length and shape could then be improved.

(2018-12-19, 7:51)Max Martin Richter Wrote: As LDraw parts are not flexible as the real parts and therefore several building options will result in collisions anyway, I would go with just one hand model.

Looks good to me. It still doesn't fit a tile without collision, but it's much better. And that's impossible anyway without some elasticity...
The bottom curve of hand could probably be simplified a bit without losing smoothness.

Not sure if this is the right thread, but it seemed a bit silly to make a whole new one for this.
LDraw part 3626bpm0 (and it's counterpart 3626cpm0) and LDraw part 3626bpmb look very much alike. In fact, I think they both represent 3626cpb0719 except one has wrong colored eyes.

(2018-12-07, 21:28)Merlijn Wissink Wrote: Not sure if this is the right thread, but it seemed a bit silly to make a whole new one for this.
LDraw part 3626bpm0 (and it's counterpart 3626cpm0) and LDraw part 3626bpmb look very much alike. In fact, I think they both represent 3626cpb0719 except one has wrong colored eyes.

Could someone clarify this?

No, the print on the backside is different. It is at Bricklink as 3626cpb0718.

@Magnus, the measured height of the hand is 4,4 mm (11 LDU) the LDraw hand is 12 LDU high

I used the hi-res because the existing hand also uses a higher resolution for the rounded slope.

Questions/Opinions:
- Shall I lower the top of the hand by one (1) LDU?
- Shall I add the rounded corner at the rop of the fingers (r= around 1 LDU)
- Shall I use standard res (16 segments) of some medium resolution (32) for the larger rounded slope.

Also the intersection between arm and hand needs some minor cleaning as well.

When looking through the "HOLD" parts I stumbled across a patterend Dish 4 x 4 with a note that the vertices do not line up.

I remembered that I had a similar issue with the Ghost Face Dish. Where, when zooming really closely in, the pattern was sliced at a multitude of vertices.

Now I looked into the original, non-patterend, Dish and I see that the cond-lines and quads do not share the same vertices. Even some of the Quads do not align, i.e. every second quad doesn't line up with the previous one.

To make a cleaner template for patterned dishes I would rather clean the 3960 one up, to get a clean template for patterned versions.

(2019-05-27, 10:25)Gerald Lasser Wrote: When looking through the "HOLD" parts I stumbled across a patterend Dish 4 x 4 with a note that the vertices do not line up.

I remembered that I had a similar issue with the Ghost Face Dish. Where, when zooming really closely in, the pattern was sliced at a multitude of vertices.

Now I looked into the original, non-patterend, Dish and I see that the cond-lines and quads do not share the same vertices. Even some of the Quads do not align, i.e. every second quad doesn't line up with the previous one.

To make a cleaner template for patterned dishes I would rather clean the 3960 one up, to get a clean template for patterned versions.

(2019-05-27, 10:25)Gerald Lasser Wrote: Even some of the Quads do not align, i.e. every second quad doesn't line up with the previous one.
To make a cleaner template for patterned dishes I would rather clean the 3960 one up, to get a clean template for patterned versions.

Yes... I already improved this part in the past, I think that the only way to get a better result (considering limited rotation matrix precision) would be to make s02 cover a 45° span and use it in mirrored/90° rotated way.

(2019-05-27, 11:17)Philippe Hurbain Wrote: Yes... I already improved this part in the past, I think that the only way to get a better result (considering limited rotation matrix precision) would be to make s02 cover a 45° span and use it in mirrored/90° rotated way.

s02 -> Increased to 45 degrees and removed condlines
s03 -> surface from s02-slices and s05 condlines
s04 NEW condlines 45 degree slice
s05 NEW complete set of condlines, can be used also for patterned dished

Now all gaps are closed and generating patterns should be much easier now!

(2019-05-30, 9:45)Philippe Hurbain Wrote: As a rule of thumb, if r>20 ldu, I use high-res. Here r=30, so...

So, here we go, I have modified the basic files of43898 to use 48 Segments

43898 -> changed to 48 segment prims and added "arings" where needed
s01 -> changed to 48 segment prims and added "arings" where needed
s05 NEW complete set of condlines, can be used also for patterned dishes

In addition I modified the only existing patterned version on the PT to be on 48 segments and I added five other patterns:

(2019-05-30, 18:04)Orion Pobursky Wrote: Purple means the post has been soft deleted. This means that Damien probably deleted his post and Philo’s post was a reply to that. I’ve restored both.

Hello, you are right, I've answered with my cell phone, and for some reason forgot that when I do this, only the "Quote" part of the post is actually posted.
As I didn't to rewrite what I've written, I choose to delete my post.

I wasn't aware that it would have also deleted Philo's one, sorry for that.

(2019-06-26, 11:43)Gerald Lasser Wrote: Ideal would be to change 11187 to the correct geometry and add an alias for 28263.

With that approach a complete compatibility cannot be guaranteed due to the different lenghts and existting models may face collision issues (though I think there is only a slim chance...)

Annoying... I think that we can't simply correct geometry, as the distance between attachment point is wrong (stud and back half bar - if this half bar can be considered as an attachment point). What we do in this case is to create correct 11187a and obsoletize 11184.

(2019-06-26, 15:12)Philippe Hurbain Wrote: Annoying... I think that we can't simply correct geometry, as the distance between attachment point is wrong (stud and back half bar - if this half bar can be considered as an attachment point). What we do in this case is to create correct 11187a and obsoletize 11184.

Another part used in the Quantum Real Explorer that needs a rework, is the Brick 1 x 1 x 2/3 Round with Bar and Clip Vertical (Part 4735)

Currently the grooves on the part are only edge lines, which make it appear smooth during renders. I have reworked it, added proper grooves and a different clip. The clip needs to be a bit narrower though...

(2019-07-07, 16:01)Gerald Lasser Wrote: Another part used in the Quantum Real Explorer that needs a rework, is the Brick 1 x 1 x 2/3 Round with Bar and Clip Vertical (Part 4735)

Currently the grooves on the part are only edge lines, which make it appear smooth during renders. I have reworked it, added proper grooves and a different clip. The clip needs to be a bit narrower though...

with narrower clip

I distinctly remember fixing this part. Are you sure there isn't a correct one in the library?

(2019-07-07, 16:01)Gerald Lasser Wrote: Another part used in the Quantum Real Explorer that needs a rework, is the Brick 1 x 1 x 2/3 Round with Bar and Clip Vertical (Part 4735)

Currently the grooves on the part are only edge lines, which make it appear smooth during renders. I have reworked it, added proper grooves and a different clip. The clip needs to be a bit narrower though...

with narrower clip

Mom not a fan of the sharp ridges. The real part is more rounded. Maybe torii instead?

(2019-07-07, 23:38)Orion Pobursky Wrote: Mom not a fan of the sharp ridges. The real part is more rounded. Maybe torii instead?

Since the part is so small, I can't be absolutely sure, but I don't think they are rounded. I think they are rectangular grooves with a flat outside. And using tori for features so small would be serious overkill. I think the walls of the divots are too sloped (should be closer to 90 degrees), resulting in the outer parts being too skinny.

(2019-07-08, 6:42)Gerald Lasser Wrote: Here's a hi-res picture of the part. It'S more a trapezoid shape. I also don't like too sharp edges, but using tori here would give us a LOT of quads...
I go ahead with those measurements, the indents will be shallower then as I used 1 LDU in the mock-up vs. 0,5 I get from the picture

I'd clearly go with the trapezium method, like s\604547s01.dat with the right ridge scaling. More is pure overkill at this scale.