+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Existing Part Edit Requests (/thread-2877.html)
Existing Part Edit Requests - Tim Gould - 2011-12-31
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.
Re: Existing Part Edit Requests - Steffen - 2011-12-31
I think the problem has this cause:
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.
Re: Existing Part Edit Requests - Tim Gould - 2011-12-31
I thought you could edit with just a along enough delay. Perhaps I misremembered.
Either way the license makes it 'legal' if impolite. And I'm willling to brave the insult if things sit too long.
For future reference _any_ part I make can and should be edited by anyone if I don't fix the errors quickly. I used to write this when I posted them.
Tim
Re: Existing Part Edit Requests - Steffen - 2012-01-01
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.
Re: Existing Part Edit Requests - Tim Gould - 2012-01-01
In truth I wouldn't be pleased if someone changed anything that wasn't a clear error or well established standard. But other than that change away if I've got a mistake.
Re: Existing Part Edit Requests - Christoph Mierowski - 2012-08-25
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
Re: Existing Part Edit Requests - Chris Dee - 2012-08-25
Thanks for pointing out these errors. New versions of these parts are now on the LDraw Parts Tracker.
4600
2559
Re: Existing Part Edit Requests - Christoph Mierowski - 2012-11-29
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?).
Re: Existing Part Edit Requests - Magnus Forsberg - 2012-11-29
I've fixed this.
973p44 is already at the Part Tracker.
3846p44 is sent to Admin for upload, together with corrected subfiles.
Re: Existing Part Edit Requests - Christoph Mierowski - 2012-11-30
Nice!
Re: Existing Part Edit Requests - Christoph Mierowski - 2012-12-01
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
2712: Technic Rotor 3 Blade - Ignacio Fernandez Galvan - 2012-12-15
There's either a variant for this piece or some instructions were printed wrongly.
This page http://www.peeron.com/scans/8855-1/9 (bottom right inset) shows the piece as it's currently modeled.
But this picture http://www.peeron.com/inv/parts/2712?img=22206 shows a notch in the axle hole.
Further, my printed instructions (printed in Germany, 1988), do show the notch.
Re: 2712: Technic Rotor 3 Blade - Michael Heidemann - 2012-12-15
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.
Re: 2712: Technic Rotor 3 Blade - Philippe Hurbain - 2012-12-15
You are right, I looked at my parts collection, there are two variants of this part, one has a regular axle hole, the other is notched.
Re: 2712: Technic Rotor 3 Blade - Magnus Forsberg - 2012-12-15
32125 was changed in the last part release since no one could find any part with just an axlehole.
That part is only known with a notch.
Re: Existing Part Edit Requests - Roland Melkert - 2013-03-29
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.
lib version 1203
Being such a important part I think it deserves to be fixed.
Re: Existing Part Edit Requests - Michael Heidemann - 2013-03-29
You are right. It is in file s\3816s01.dat. If you have turned on random colors you will see the flickering very well.
Minifig leg is wrong (was: Re: Existing Part Edit Requests) - Magnus Forsberg - 2013-04-03
IMO, there are more problems in 3816.
1.)
Could someone please explain why the foot isn't placed correctly?
1 16 -10 -15 0 6 0 0 0 60 0 0 0 6 4-4cyli.dat
1 16 10 -15 0 6 0 0 0 60 0 0 0 6 4-4cyli.dat
1 16 0 20 0 20 0 0 0 20 0 0 0 10 box0.dat
1 34 20 12 0 0 -40 0 9.5 0 0 0 0 -9.5 4-4cyli.dat
1 13 0 0 0 1 0 0 0 1 0 0 0 1 3815.DAT
1 13 0 12 0 1 0 0 0 1 0 0 0 1 3816.DAT
1 4 0 12 0 1 0 0 0 1 0 0 0.035 1 3817.DAT
I think it should be moved back 1 ldu, so that it fits inside the box-prim in my example (pink parts).
The red leg is tweaked to show what I think is wrong
2.)
This error gets even more obvious if you make a model like this:
1 6 60 0 0 1 0 0 0 1 0 0 0 1 3815.DAT
1 7 60 12 0 1 0 0 0 1 0 0 0 1 3816.DAT
1 7 60 12 0 -1 0 0 0 1 0 0 0 -1 3816.DAT
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?
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests) - Michael Heidemann - 2013-04-04
I think you have explained it very well!
I have currently not thought about how to fix.
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.
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests) - Tim Gould - 2013-04-04
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.
Or am I missing something?
Tim
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests) - Philippe Hurbain - 2013-04-05
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.
Re: Existing Part Edit Requests - Christoph Mierowski - 2013-04-16
Did anyone investigate this issue?
Wrong part number - Christoph Mierowski - 2014-06-08
4770.DAT (Electric Light & Sound Coloured Globe) should be 4773.dat.
bricklink and peeron list it as 4773.dat:
bricklink
peeron
Edit: Ok it seems they are wrong: LDD has it as 4770.
Re: Wrong part number - Willy Tschager - 2014-06-08
4773 is the lid of the Electric Light & Sound Brick 2 x 2 x 1.333 Siren. I know it 'cos I opened the part when I authored the part (12 years ago :-)
http://news.lugnet.com/cad/dat/parts/?n=4221
http://news.lugnet.com/cad/dat/parts/?n=5195
Please read also the comment in 4773a.dat
0 // True Part number is 4773, but that was incorrectly used in the Official
0 // Library for 4770. To maintain backward compatibility this is 4773a.
w.
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests) - Nils Schmidt - 2015-11-21
I would like to create the 3815b, 3816b and 3817b variants.
With LPC and LDPartEditor at hand, it is a feasible task to transfer old patterns to the new variant.
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests) - Chris Dee - 2015-11-22
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.
Re: Minifig leg is wrong - Nils Schmidt - 2015-11-22
I just wanted to be cautious. The change could "break" some models.
Here is an image of my current progress. The yellow/green one is the corrected version.
I use a vernier caliper to re-measure the part. 3815 is fine and need no modification.
![[Image: z-IGtb72AP0EBwsKK8gC6ULm-ieDJKf39E64TcjwHY0=w1920-h1080]](https://lh3.googleusercontent.com/z-IGtb72AP0EBwsKK8gC6ULm-ieDJKf39E64TcjwHY0=w1920-h1080)
Re: Minifig leg is wrong - Chris Dee - 2015-11-22
Nothing will break if we retain the existing files (but flag them as obsolete), and create new 3815a, 3816a and 3817a files.
Re: Minifig leg is wrong - Nils Schmidt - 2015-11-23
Marking the original files as obsolete and creating new parts will result in a lot of duplicated legs in our library.
All patterned parts need a rework, too.
Re: Minifig leg is wrong - Chris Dee - 2015-11-23
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.
RE: Existing Part Edit Requests - Willy Tschager - 2016-06-02
I'd like to bring these two parts here 'cos it's much easier discussing it:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=3855
http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=3855a
http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=3855b
I do not think that the origin of the current official part should be change.
w.
RE: Existing Part Edit Requests - Philippe Hurbain - 2016-06-03
Either we make all of them match current origin for the sake of standardization, or we move the origin in the middle point of the bump to allow easy tilting. I favor the second solution.
RE: Existing Part Edit Requests - Willy Tschager - 2016-06-03
(2016-06-03, 6:57)Philippe Hurbain Wrote: we move the origin in the middle point of the bump to allow easy tilting. I favor the second solution.
This will break a million sets ...
w.
RE: Existing Part Edit Requests - Philippe Hurbain - 2016-06-03
Sorry, I meant set the new origin in the middle of bumps for 3855a and b but compensate the offset in movedto 3855 shortcut to keep compatibility.
RE: Existing Part Edit Requests - Tomas Kralicek - 2016-12-26
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?
RE: Existing Part Edit Requests - Magnus Forsberg - 2016-12-26
(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.
RE: Existing Part Edit Requests - Tomas Kralicek - 2016-12-27
(2016-12-26, 21:44)Magnus Forsberg Wrote:(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.
RE: Existing Part Edit Requests - Steffen - 2016-12-27
>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.
RE: Existing Part Edit Requests - Magnus Forsberg - 2016-12-27
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?
RE: Existing Part Edit Requests - Tomas Kralicek - 2016-12-28
I agree as this is the same approach as with the part 4864.
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?
The version a and b are on the rebrickable:
![[Image: 800x1333.jpg]](http://bricksafe.com/files/sheo/Temp/Slope%202x2x3.jpg/800x1333.jpg)
RE: Existing Part Edit Requests - Philippe Hurbain - 2016-12-28
Quote:is it enough to email a request to parts<at>ldraw.org?
Yes, that's the process...
RE: Existing Part Edit Requests - Thomas Chen - 2018-03-21
Hi,
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
RE: Existing Part Edit Requests - Philippe Hurbain - 2018-03-22
Good point, investigating...
RE: Existing Part Edit Requests - Chris Dee - 2018-03-23
(2018-03-21, 20:58)Thomas Chen Wrote: Hi,
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.
RE: Existing Part Edit Requests - Magnus Forsberg - 2018-03-25
Primitive substitution (in LDView) doesn't seem to work on t04ounit.dat, but it worked on r04o1000.dat
RE: Existing Part Edit Requests - Travis Cobbs - 2018-03-26
(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.
RE: Existing Part Edit Requests - Chris Dee - 2018-03-26
(2018-03-26, 1:38)Travis Cobbs Wrote:(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.
RE: Existing Part Edit Requests - Santeri Piippo - 2018-03-26
(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.
RE: Existing Part Edit Requests - Chris Dee - 2018-03-26
(2018-03-26, 16:17)Santeri Piippo Wrote:(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.
RE: Existing Part Edit Requests - Magnus Forsberg - 2018-03-26
(2018-03-26, 18:48)Chris Dee Wrote: OK - I have reversed the changes and made t04ounit a ~Moved to for r04o1000.
I like the logic of this decision.