Existing Part Edit Requests


Existing Part Edit Requests
#1
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.
Reply
Re: Existing Part Edit Requests
#2
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.
Reply
Re: Existing Part Edit Requests
#3
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
Reply
Re: Existing Part Edit Requests
#4
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.
Reply
Re: Existing Part Edit Requests
#5
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.
Reply
Re: Existing Part Edit Requests
#6
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
Reply
Re: Existing Part Edit Requests
#7
Thanks for pointing out these errors. New versions of these parts are now on the LDraw Parts Tracker.
4600
2559
Chris (LDraw Parts Library Admin)
Reply
Re: Existing Part Edit Requests
#8
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?).
Reply
Re: Existing Part Edit Requests
#9
I've fixed this.

973p44 is already at the Part Tracker.
3846p44 is sent to Admin for upload, together with corrected subfiles.
Reply
Re: Existing Part Edit Requests
#10
Nice!
Reply
Re: Existing Part Edit Requests
#11
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
Reply
Re: Existing Part Edit Requests
#22
Did anyone investigate this issue?
Reply
2712: Technic Rotor 3 Blade
#12
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.
Reply
Re: 2712: Technic Rotor 3 Blade
#13
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.
Reply
Re: 2712: Technic Rotor 3 Blade
#14
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.
Reply
Re: 2712: Technic Rotor 3 Blade
#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.
Reply
Re: Existing Part Edit Requests
#16
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.
Reply
Re: Existing Part Edit Requests
#17
You are right. It is in file s\3816s01.dat. If you have turned on random colors you will see the flickering very well.
Reply
Minifig leg is wrong (was: Re: Existing Part Edit Requests)
#18
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?
Reply
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests)
#19
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.
Reply
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests)
#20
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
Reply
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests)
#21
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.
Reply
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests)
#25
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.
Reply
Re: Minifig leg is wrong (was: Re: Existing Part Edit Requests)
#26
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.
Chris (LDraw Parts Library Admin)
Reply
Re: Minifig leg is wrong
#27
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]
Reply
Re: Minifig leg is wrong
#28
Nothing will break if we retain the existing files (but flag them as obsolete), and create new 3815a, 3816a and 3817a files.
Chris (LDraw Parts Library Admin)
Reply
Re: Minifig leg is wrong
#29
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.
Reply
Re: Minifig leg is wrong
#30
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.
Chris (LDraw Parts Library Admin)
Reply
Wrong part number
#23
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.
Reply
Re: Wrong part number
#24
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.
LEGO ergo sum
Reply
RE: Existing Part Edit Requests
#31
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.
LEGO ergo sum
Reply
RE: Existing Part Edit Requests
#32
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.
Reply
RE: Existing Part Edit Requests
#33
(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.
LEGO ergo sum
Reply
RE: Existing Part Edit Requests
#34
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.
Reply
RE: Existing Part Edit Requests
#35
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?
Reply
RE: Existing Part Edit Requests
#36
(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.
Reply
RE: Existing Part Edit Requests
#37
(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.
Reply
RE: Existing Part Edit Requests
#38
>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.
Reply
RE: Existing Part Edit Requests
#39
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?
Reply
RE: Existing Part Edit Requests
#40
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]
Reply
RE: Existing Part Edit Requests
#41
Quote:is it enough to email a request to parts<at>ldraw.org?

Yes, that's the process...
Reply
RE: Existing Part Edit Requests
#42
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
Reply
RE: Existing Part Edit Requests
#43
Good point, investigating...
Reply
RE: Existing Part Edit Requests
#44
(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.
Chris (LDraw Parts Library Admin)
Reply
RE: Existing Part Edit Requests
#45
Primitive substitution (in LDView) doesn't seem to work on t04ounit.dat, but it worked on r04o1000.dat
Reply
RE: Existing Part Edit Requests
#46
(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.
Reply
RE: Existing Part Edit Requests
#47
(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.
Chris (LDraw Parts Library Admin)
Reply
RE: Existing Part Edit Requests
#48
(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.
Reply
RE: Existing Part Edit Requests
#49
(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.
Chris (LDraw Parts Library Admin)
Reply
RE: Existing Part Edit Requests
#50
(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.
Reply
RE: Existing Part Edit Requests
#51
(2018-03-26, 20:54)Magnus Forsberg Wrote:
(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.

Thanks. Please review the (F)ixed parts at http://www.ldraw.org/cgi-bin/ptscan.cgi?q=t04ounit so that they don't linger too long on the Parts Tracker.
[url=http://www.ldraw.org/cgi-bin/ptscan.cgi?q=t04ounit][/url]
Chris (LDraw Parts Library Admin)
Reply
RE: Existing Part Edit Requests
#52
Chris, could you rename these tori too, for consistency and primitive substitution?
http://www.ldraw.org/cgi-bin/ptdetail.cg...8qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat
Reply
RE: Existing Part Edit Requests
#53
(2018-03-27, 7:46)Philippe Hurbain Wrote: Chris, could you rename these tori too, for consistency and primitive substitution?
http://www.ldraw.org/cgi-bin/ptdetail.cg...8qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat

That's done.
Chris (LDraw Parts Library Admin)
Reply
RE: Existing Part Edit Requests
#54
(2018-03-27, 7:46)Philippe Hurbain Wrote: Chris, could you rename these tori too, for consistency and primitive substitution?
http://www.ldraw.org/cgi-bin/ptdetail.cg...8qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat

They look good, but are unused. Why were they made?
Reply
RE: Existing Part Edit Requests
#56
(2018-03-27, 19:17)Magnus Forsberg Wrote:
(2018-03-27, 7:46)Philippe Hurbain Wrote: Chris, could you rename these tori too, for consistency and primitive substitution?
http://www.ldraw.org/cgi-bin/ptdetail.cg...8qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...4qunit.dat

They look good, but are unused. Why were they made?

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\".
Reply
RE: Existing Part Edit Requests
#55
Quote:I like the logic of this decision.

Me too.
Reply
RE: Existing Part Edit Requests
#57
I just came across parts/3660.dat and noticed that the stud rotation is incorrect.
The part needs both studs to be rotated 90 degrees clockwise, so on the following picture ...

.png   3660.png (Size: 6.72 KB / Downloads: 485)
... the 'LEGO' logo would be upside down.
Reply
RE: Existing Part Edit Requests
#58
just go ahead, correct it and send the corrected file to the Parts Tracker admin so he can upload it to the Parts Tracker Smile
Reply
RE: Existing Part Edit Requests
#59
(2018-04-20, 2:18)Steffen Wrote: just go ahead, correct it ...

Done. For the record: I made the change to 3660s01.dat.
(Now I know how to rotate parts too!) Smile
Reply
RE: Existing Part Edit Requests
#60
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.
Reply
RE: Existing Part Edit Requests
#61
(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.
Chris (LDraw Parts Library Admin)
Reply
Minifig Hand 3820.dat
#62
I was authoring some Minifig accessory when I came across the measurements.

The gap between thumb and fingers with 3820.dat is 4 LDU or 1,6 mm, however measuring a real hand I end up with 2,6 mm or 6.5 LDU

The gap at 93061.dat is 7.4 LDU

Is there another hand somewhere in the Lib with the correct spacing?
Reply
RE: Minifig Hand 3820.dat
#63
(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.
Reply
RE: Minifig Hand 3820.dat
#66
Who is gonna fix this?

w.
LEGO ergo sum
Reply
RE: Minifig Hand 3820.dat
#67
(2018-12-18, 20:47)Willy Tschager Wrote: Who is gonna fix this?

w.
what do you think of this?
Rough draft
   


Attached Files
.dat   3820_new.dat (Size: 54.22 KB / Downloads: 3)
Reply
RE: Minifig Hand 3820.dat
#68
I personally think that the new one closes too far.
Reply
RE: Minifig Hand 3820.dat
#69
(2018-12-19, 1:42)Travis Cobbs Wrote: I personally think that the new one closes too far.

You think it is still closing too far?
I didn't explain the picture, new one is in the back, so it is wider.

Measuring the hand, the outer diameter could be slightly larger, by approx .5 LDU. However to keep compatibility at max, i.e. the hand can fit into a stud4, the outer diameter shall be kept.

This compatibility issue raises another point:
- The hand can fit into a stud4 only without having a grip on a bar
- If the hand has a grip on a bar, it does not fit into an anti-stud.

However, I would avoid having to use two different hands? What do you think?
Reply
RE: Minifig Hand 3820.dat
#70
(2018-12-19, 7:20)Gerald Lasser Wrote:
(2018-12-19, 1:42)Travis Cobbs Wrote: I personally think that the new one closes too far.

You think it is still closing too far?
I didn't explain the picture, new one is in the back, so it is wider.

Measuring the hand, the outer diameter could be slightly larger, by approx .5 LDU. However to keep compatibility at max, i.e. the hand can fit into a stud4, the outer diameter shall be kept.

This compatibility issue raises another point:
- The hand can fit into a stud4 only without having a grip on a bar
- If the hand has a grip on a bar, it does not fit into an anti-stud.

However, I would avoid having to use two different hands? What do you think?

I like your solution, but I'll need to check against a real part.

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.

/Max
Reply
RE: Minifig Hand 3820.dat
#71
(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.
Definitely yes, just one hand!!!
Reply
RE: Minifig Hand 3820.dat
#72
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.
Reply
RE: Minifig Hand 3820.dat
#73
(2018-12-19, 9:10)Philippe Hurbain Wrote: The bottom curve of hand could probably be simplified a bit without losing smoothness.

Yes, it looks good, but keep the curve in normal res. I see no reason to use a hi-res cyli.

How about the difference in height? 
Compared to ldd data, the top of the hand should be lowered.
Reply
RE: Minifig Hand 3820.dat
#74
(2018-12-19, 7:20)Gerald Lasser Wrote:
(2018-12-19, 1:42)Travis Cobbs Wrote: I personally think that the new one closes too far.

You think it is still closing too far?
I didn't explain the picture, new one is in the back, so it is wider.

Measuring the hand, the outer diameter could be slightly larger, by approx .5 LDU. However to keep compatibility at max, i.e. the hand can fit into a stud4, the outer diameter shall be kept.

Sorry, I thought the newer one was in the front. My bad.
Reply
RE: Existing Part Edit Requests
#64
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?
Reply
RE: Existing Part Edit Requests
#65
(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.
Reply
RE: Existing Part Edit Requests
#75
@Travis, I shall use colour in future  Smile

@all, Hand outer Diameter measured:
- normal, unloaded: 5 mm
- grip on a standard bar: around 5,1 mm
- grip on a Tile: 5,3 mm !!!

@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.
Reply
RE: Existing Part Edit Requests
#76
(2018-12-19, 21:32)Gerald Lasser Wrote: - Shall I lower the top of the hand by one (1) LDU?
I think it can't hurt.


Quote:- Shall I add the rounded corner at the rop of the fingers (r= around 1 LDU)
a simple 45° bevel at this size would be enough and woudn't cost an arm, triangle wise.

Quote:- Shall I use standard res (16 segments) of some medium resolution (32) for the larger rounded slope.
There's no need to have a precise cylinder structure there.

Attached my take, with a bevel on top and a simplified curve at bottom. 1ldu top move not done. Notice how the triangulation is done to get as good smoothing as possible.


Quote:Also the intersection between arm and hand needs some minor cleaning as well.
Yes!


Attached Files
.dat   3820_new.dat (Size: 56.44 KB / Downloads: 5)
Reply
RE: Existing Part Edit Requests
#77
I like all the changes Philo did on this updated hand, but I would also like to have the top lowered.
Reply
RE: Existing Part Edit Requests
#78
(2018-12-20, 18:00)Magnus Forsberg Wrote: I like all the changes Philo did on this updated hand, but I would also like to have the top lowered.

I will incorporate those
Reply
Fix for 4x4 dish
#79
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.
Reply
RE: Fix for 4x4 dish
#80
(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.

Just fix it.

w.
LEGO ergo sum
Reply
RE: Fix for 4x4 dish
#81
(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.
Reply
RE: Fix for 4x4 dish
#82
(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.

I'll do it
Reply
RE: Existing Part Edit Requests
#83
I re-did the subfiles of 3960

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!

I will send s02 and s03 to Chris
Reply
RE: Existing Part Edit Requests
#84
That was quick. Thanks for the job.

w.
LEGO ergo sum
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#85
Dear all,

What do you think of moving the Dish 3x3 to 48-segments from the current 16.

See the Orient Pattern as comparison:

   
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#86
Looks much better indeed.
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#87
As a rule of thumb, if r>20 ldu, I use high-res. Here r=30, so...
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#90
(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:

   
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#88
Why can't I see the two posts following this post?
One of them even have a different colour. It is lilac, instead of light blue and lighter blue.

   
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#89
(2019-05-30, 17:41)Magnus Forsberg Wrote: Why can't I see the two posts following this post?
One of them even have a different colour. It is lilac, instead of light blue and lighter blue.

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.
Reply
RE: Existing Part Edit Requests - Improving Dish 3 x 3
#91
(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.
Reply
Snowshoes
#92
I noticed yesterday that the snowshoe, coming with the current Arctic Sets, is actually another type.

Now comes the dilemma. In our library there is the 30284, the original one and the 11187 which is currently listed as an alias.

At BL and Brickset however, the 11187 is NOT the same design as the 30284. Moreover there is another variant, the 28263, which is an alias to 11187.

The 11187 is official, but in reality it has another origin that 30284. Compared to 30284 it has a short front end and a long backend.

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...)

   
Reply
RE: Snowshoes
#93
(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.
Reply
RE: Snowshoes
#94
(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.

Thanks for the advice Philo!

I will go ahead and
  • brush up the new 11187a with thenew geometry.
  • Add the alias for the 28263
  • send the obsolete file to Chris
Reply
Barrel 2 x 2 - 2489.dat needs an update
#95
I did my current favourite set, the Quantum Realm Explorer, and I was at first stunned what I got at the engines. Those are made from barrels (2489) and the result did not look nice.

with current official part:
   


with updated barrel:
   

I did a quick mock-up and I think I will upload them, which is more or less ready to use...
   


Attached Files
.dat   barrel.dat (Size: 26.37 KB / Downloads: 0)
Reply
RE: Existing Part Edit Requests - 4735
#96
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...

   


.png   Ldraw_4735_new-old.PNG (Size: 56.67 KB / Downloads: 100)

with narrower clip
   
Reply
RE: Existing Part Edit Requests - 4735
#97
(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?
Reply
RE: Existing Part Edit Requests - 4735
#98
(2019-07-07, 21:15)Orion Pobursky Wrote: I distinctly remember fixing this part. Are you sure there isn't a correct one in the library?

This is the screenshot of the part from my last download of the complete.zip after the 2019-01 update:
   

This corresponds also to the last !HISTORY entry when you download it from the PT.
Reply
RE: Existing Part Edit Requests - 4735
#99
(2019-07-07, 22:31)Gerald Lasser Wrote: This is the screenshot of the part from my last download of the complete.zip after the 2019-01 update:


This corresponds also to the last !HISTORY entry when you download it from the PT.

I checked that too. It would have been quite a while ago. I might be misremembering.
Reply
RE: Existing Part Edit Requests - 4735
(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?
Reply
RE: Existing Part Edit Requests - 4735
(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.
Reply
RE: Existing Part Edit Requests
I checked all the updates, I only find it in its initial release here: LDraw.org Parts Update 2009-02 - Sep 16, 2009

may be still on your HD?
Reply
RE: Existing Part Edit Requests
(2019-07-07, 22:55)Gerald Lasser Wrote: I checked all the updates, I only find it in its initial release here: LDraw.org Parts Update 2009-02 - Sep 16, 2009

may be still on your HD?

I just checked every backup I have. If it ever existed, it's gone now.
Reply
RE: Existing Part Edit Requests
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
Reply
RE: Existing Part Edit Requests
You might check what I did on 71342.dat
Minifig Bugle.

w.
LEGO ergo sum
Reply
RE: Existing Part Edit Requests
(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.
Reply
RE: Existing Part Edit Requests
@all, thanks for your opinions, I go ahead with this one


.png   Ldraw_4735_Final.PNG (Size: 47.16 KB / Downloads: 57)
Reply
RE: Existing Part Edit Requests
(2019-07-08, 8:58)Gerald Lasser Wrote: @all, thanks for your opinions, I go ahead with this one
Isn't this very close to the minifig tool handle?
Spanner, screwdriver, hammer. 6246a-f and 11402a-i
That design is placed in subfiles. Could they be used?
Reply
RE: Existing Part Edit Requests
(2019-07-08, 11:31)Magnus Forsberg Wrote: Isn't this very close to the minifig tool handle?
Spanner, screwdriver, hammer. 6246a-f and 11402a-i
That design is placed in subfiles. Could they be used?

No, they have one too many groove...
I tried looking them up as well
Reply
RE: Existing Part Edit Requests
(2019-07-08, 11:49)Gerald Lasser Wrote: No, they have one too many groove...
I tried looking them up as well

You could just have one groove as a primitive/subfile.
Reply
RE: Existing Part Edit Requests
(2019-07-08, 8:58)Gerald Lasser Wrote: @all, thanks for your opinions, I go ahead with this one
Imho, bottom of grooves cylis are just wasting triangles (though you caould use a single cyli for whole length...)
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)