LDraw.org Discussion Forums

It seems that there is a need for updating the naming scheme that Primgen2 uses for the primitives.
Here my suggestion:
x, y, z are values that will be substituted by primgen2 for the dimension of the part.
cylinder: x-ycyli.dat : always use cyli
disc: x-ydisc.dat : always use disc
ndisc: x-yndis.dat : always use ndis
chord: x-ychrd.dat : always use chrd
cone: x-yconz.dat : always use con
ring:x-yringz.dat : always use ring
circle: x-yedge.dat : always use edge

The length of the filename is not important anymore because I think we will not reach 25 characters.

If this should be common used, I am going to change Primgen2 quickly.

I am inclined to agree. Would somebody have time to assess the scope of impact on existing official primitives (ldraw/p and ldraw/p/48)?

Thanks for bringing this up for discussion.

Analysis coming up. I can tell straight up, though, that changing 'rin' to 'ring' would be a massive change.

Yes, that is true. With LDFind I made a quick search for 'ring' and found:
Hi-Res Ring 40 x 0.2292 C:\ldraw\p\48\11-48r40.dat
Hi-Res Ring 42 x 0.0833 C:\ldraw\p\48\1-12ri42.dat
Ring 11 x 0.25 C:\ldraw\p\1-4rin11.dat
Ring 8 x 0.375 C:\ldraw\p\3-8ring8.dat

So for ring we have at least 'r', 'ri', 'rin' and 'ring' already in our library.

I believe that for the other primitives we will have similar results. So we need to solve this problem first.

I would go with:
Keep the already official files like they are. Introduce the new naming scheme quickly for new primitives.

Okay so, assuming we leave 'rin' files alone since there's just too many of those to even consider it IMO: I found 51 official primitives that would need renaming. A total of 25 part/subpart files would have to be updated accordingly:

List of primitives:

List of affected part files:

List of matches, sans duplicates (which parts referenced which primitives):

Why don't we create MOVEDTOs? Then all new parts will use the new scheme and all old parts will be fine until updated

That is actually not too bad. I can create the new files by renaming the existing ones, so please don't start submitting replacements.

I'd like to leave "~Moved to" files in place so that we don't have to fix all the official parts/subparts in one tranche. It is inevitable that when the parts get re-cycled through the Parts Tracker, someone will want to make improvements which could hold up the whole process.

Does the parts tracker already check for usage of "~Moved to" sub-parts and primitives in submitted parts and auto-generate a failure?

No - not at present.

All the "moves" have now been done on the Parts Tracker. I've not yet checked if there are any unofficial primitives that need renaming.

I don't understand this.

Is it correct that all the hi-res prims are renumbered without a moved to-file?
Is it correct that all the hi-res prims should have both "Unofficial_48_Primitive" and a "UPDATE YYYY-XX" ?
Is it correct that the only normal resolution primitive should have a "Moved to-" file?

Magnus Forsberg Wrote:Is it correct that all the hi-res prims are renumbered without a moved to-file?

No, the ~Moved to files are there e.g. http://www.ldraw.org/cgi-bin/ptdetail.cg...48ri32.dat, but the Name: line hasn't been updated correctly (I'll fix that).

Magnus Forsberg Wrote:Is it correct that all the hi-res prims should have both "Unofficial_48_Primitive" and a "UPDATE YYYY-XX" ?

No, that's a bug in the rename script (probably the first time it has been used on a p/48/ file)

Magnus Forsberg Wrote:Is it correct that the only normal resolution primitive should have a "Moved to-" file?

Not sure what you mean. Can you point to an example?

Ok, it seems I have to update PrimGen2 immediately.

Before I upload it I like someone to test it. Who likes to test the new version??

Edit:
The new version is already online. Please see this post.

OK, thanks.
When I wrote this none of the hi-res had a move to-file. They do now.

Mike found this strange file, and I found that the only file that got a moved to-file was this one.
It still has an incorrect header. Could you please fix that one too?

As fas as I can see both files are now fine.

I think I've found some more files.

Official files
p\1-16ri19.dat
p\3-16ri11.dat
p\3-16ri12.dat
p\3-16ri13.dat
p\3-16ri14.dat
p\5-16ri12.dat

p\48\19-48chr.dat

Unofficial files
p\1-16ri11.dat
p\1-16ri22.dat
p\1-16ri57.dat
p\3-16ri10.dat
p\3-16ri15.dat
p\3-16ri19.dat
p\3-16ri22.dat
p\4-4ri101.dat

p\48\4-4cone25.dat
p\48\4-4cone52.dat

and one of the files p\13-16cyl.dat or p\13-16cyli.dat should be deleted/renumbered
and p\11-16cyl.dat should be renumbered

Thanks - done.

I've found another two files that IMO should not be renumbered.

Unofficial
p\48\1-4cone12.dat
p\48\1-6cone1.dat

Michael Heidemann Wrote:cone: x-yconz.dat : always use con

Please change them back to 1-4con12.dat and 1-6con1.dat

That's done.