That'll be a lot of work! now the big question is will it happen before or
after the head merge
I'm out of the loop, what is the head merge? I quickly searched for forum
and didn't find any answers except it was supposed to be done at the end
of May.
That'll be a lot of work! now the big question is will it happen before or
after the head merge
I'm out of the loop, what is the head merge? I quickly searched for forum
and didn't find any answers except it was supposed to be done at the end
of May.
They are merging all blocked, hollow, and vented stud heads. They already did
it for the base entry and are planning to do it for the printed versions but
that’s been delayed.
Studio doesn't care about minifigures' IDs, it only cares about parts.
one bright spot for Studio... about that 1x2 plate
Ah but the problems with the 1x2 plate aren't due to a catalogue change (nothing
changed in the catalogue), they are due to a 3D model change, how LDraw handles
them, and how Studio is not prepared to handle them
NOOOOO!!!! Now brickognize won't work at full power
nor rebrickable
nor brickset
and probably studio
are there no other prefixes? wouldn't it have been much less disruptive to
start a new series with a prefix sup or sho or shm
Just baffling that catalog admins operate as if there are no other sites or programs
that use these numbers!
AB
BrickLink owns the IP for minifigure numbers that all other sites copy, so BrickLink
is able to adjust the numbers as needed when needed. It is up to other outside
parties to adjust their sites accordingly if they want to continue to use the
BrickLink IP. Otherwise, they are all free to start their own numbering schemes.
Having said that, I believe the rebuilt BrickLink should use links to the mostly
immutable database keys for all catalog items instead of using links to item
numbers that can -- and will -- change. In that way, BrickLink would
far lessen its impact on the rest of the larger LEGO internet community.
Until that time, though, we will do what is necessary on BrickLink to keep BrickLink
organized and structured as well as possible. For example, no one would want
BrickLink to start using a new series of numbers for a minifigure series when
one is already established. Imagine the Star Wars community if we would have
just started stw001 when we got up to sw999! I wouldn't want to suffer that
wrath!
Imagine the Star Wars community if we would have
just started stw001 when we got up to sw999!
That would be strange if a set had straddled the numbering change, and the person
doing the inventory had to choose which figures were sw and which were stw. And
another change to the numbering (swa001 ?) would be needed much quicker than
for the 4 digit system. And again, and again, ...
BrickLink owns the IP for minifigure numbers that all other sites copy, so BrickLink
is able to adjust the numbers as needed when needed.
I just need it explained why any re-numbering is necessary just because a series
goes from 3 digits to 4.
I guess I just never understand the need for leading zeroes in general. What
is so terrible about going from 999 to 1000 and NOT adding a leading zero? If
computers are so smart, they should be able to recognize and "sort" numbers
without the need for leading zeroes; otherwise isn't it due to shitty software
or crappy/lazy coding?
But you missed Shiny_Stuff's point in the part of the quote you removed.
I guess I just never understand the need for leading zeroes in general. What
is so terrible about going from 999 to 1000 and NOT adding a leading zero? If
computers are so smart, they should be able to recognize and "sort" numbers
without the need for leading zeroes; otherwise isn't it due to shitty software
or crappy/lazy coding?
The need for the zero arises from using a lexicographic sort on the entries,
which is the easiest "sort" function to implement. But there are other
options (e.g. https://www.gnu.org/software/coreutils/manual/html_node/Version-sort-overview.html)
that would be more difficult to implement in the various software that use the
BL numbers.
So I guess the re-numbering is necessary, not because there is no other option,
but because periodically updating the numbers on a series of minifigures is much
more manageable than finding a developer to rewrite the sorting functionality
on a site that may have more pressing maintenance issues.
that would be more difficult to implement in the various software that use the
BL numbers.
So I guess the re-numbering is necessary, not because there is no other option,
but because periodically updating the numbers on a series of minifigures is much
more manageable than finding a developer to rewrite the sorting functionality
on a site that may have more pressing maintenance issues.
It's not really about “rewrit[ing] the sorting functionality,” which sounds
like one would need to reimplement the whole thing from scratch. One just need
to change a few lines of code here and there.
The main problem on BL is where “here and there” are (spaghetti code and big
ball of mud…)
(
Well, there's also the problem that the sorting should be done by the database
and there's this principle in databases: you shouldn't have to “massage”
your data everytime you use it.
Sorting by “natural order” means that you are “massaging” the IDs everytime you
use them (basically, splitting the IDs as prefix+number).
So, in a proper database, you'd rather either:
A. Split the ID column in two columns: prefix and number; and you sort on both
and everytime you need the ID, you need to concatenate the two values, which
is also bad and could be solved by having three columns (ID, prefix, number)
but that's redundancy and it's bad too (because there can be inconsistencies,
where ID ≠ prefix+number, and so you need checks everytime to touch to ID).
B. Or add a “sorting order ID” column to sort on (and that column woubld actually
be the ID with the leading zeroes inserted).
So it's simpler to just have the leading zeroes in the IDs.
)
Thanks! It took me awhile to figure that out after posting. I was wondering why
my links never seemed to work!
that would be more difficult to implement in the various software that use the
BL numbers.
So I guess the re-numbering is necessary, not because there is no other option,
but because periodically updating the numbers on a series of minifigures is much
more manageable than finding a developer to rewrite the sorting functionality
on a site that may have more pressing maintenance issues.
It's not really about “rewrit[ing] the sorting functionality,” which sounds
like one would need to reimplement the whole thing from scratch. One just need
to change a few lines of code here and there.
The main problem on BL is where “here and there” are (spaghetti code and big
ball of mud…)
(
Well, there's also the problem that the sorting should be done by the database
and there's this principle in databases: you shouldn't have to “massage”
your data everytime you use it.
Sorting by “natural order” means that you are “massaging” the IDs everytime you
use them (basically, splitting the IDs as prefix+number).
That's a very good point. And as the part number's primary use is as
a database key, it makes a lot of sense to keep the leading zeros.
So, in a proper database, you'd rather either:
A. Split the ID column in two columns: prefix and number; and you sort on both
and everytime you need the ID, you need to concatenate the two values, which
is also bad and could be solved by having three columns (ID, prefix, number)
but that's redundancy and it's bad too (because there can be inconsistencies,
where ID ≠ prefix+number, and so you need checks everytime to touch to ID).
B. Or add a “sorting order ID” column to sort on (and that column woubld actually
be the ID with the leading zeroes inserted).
So it's simpler to just have the leading zeroes in the IDs.
)
The sorting work-arounds are not only in the BL part numbering, but also for
many of the part names. By default, the catalog page for a category sorts by
part name. Check this one (the "Technic, Axle" category):
The sorting work-arounds are not only in the BL part numbering, but also for
many of the part names. By default, the catalog page for a category sorts by
part name. Check this one (the "Technic, Axle" category):
The names for shorter axles have double spaces in front of their length, so the
4L sorts before the 12L.
Of course this would be even more involved to get the sorting right without changing
its name.
Not that I am complaining, it works just fine.
Niek.
That sounds intriguing! I can't see the double spaces on the link though.
Is there some sort of HTML sanitation going on that is stripping the extra space
before the text is displayed but after the sorting has already been accomplished?
BrickLink owns the IP for minifigure numbers that all other sites copy, so BrickLink
is able to adjust the numbers as needed when needed.
I just need it explained why any re-numbering is necessary just because a series
goes from 3 digits to 4.
With the sorting routines that BrickLink has in place (mainly alphanumeric),
additional zeroes are needed on the front of the numbers to keep the sort routines
functional. Otherwise, the minifigures would not sort properly.
The sorting routines could be modified to make this a moot point, but that would
require development from the BrickLink side. Since that is likely not going to
happen until at least a re-platforming of the entire site, we are forced to keep
the archaic systems functional.
I hope that helps.
Cheers,
Randy
I guess I just never understand the need for leading zeroes in general. What
is so terrible about going from 999 to 1000 and NOT adding a leading zero? If
computers are so smart, they should be able to recognize and "sort" numbers
without the need for leading zeroes; otherwise isn't it due to [bad] software
or lazy coding?
____
Quote edited for language so this post will not get canceled.
We've not imported the data with the changes yet but once we have it won't
take long to get everything linked again. We did it for Star Wars a few years
ago.
In hindsight all minifigs should have been given 4 number digits but also started
with 3 letters too in order to give everything continuity with less chance of
abbreviations already being taken should future themes need to be considered/implemented
In hindsight all minifigs should have been given 4 number digits
In hindsight, all simple to use numbering systems ever created for organizing
data should have been done differently. In other words, almost all numbering
systems that are easy to use are not future proof. The way of the world has always
been as data needs change, data gets updated.
You can think of it like roadways. In hindsight, all of them should have been
made from the beginning with at least six to eight lanes, right? Nope. Roadways
are made for the traffic they have at the time and most of them are never future
proof.
but also started
with 3 letters too in order to give everything continuity with less chance of
abbreviations already being taken should future themes need to be considered/implemented
The set of 2-character abbreviations plus the set of 3-character abbreviations
is always greater than just the set of 3-character abbreviations, so using 2-character
abbreviations allows for _less_ of a chance of things already being used, not
more.
In hindsight, all simple to use numbering systems ever created for organizing
data should have been done differently. In other words, almost all numbering
systems that are easy to use are not future proof. The way of the world has always
been as data needs change, data gets updated.
I agree with this! You should see how messily numbered my inventory drawers are!
I've got:
A-008 thru A-263
B and C are trays that are no longer used.
D-0025 thru D-0152
E-001 thru E-360
F-01 thru F-48
and then a satellite bin of drawers called "Gateway" because the contents
originated from a Gateway computer box.
In hindsight all minifigs should have been given 4 number digits
In hindsight, all simple to use numbering systems ever created for organizing
data should have been done differently. In other words, almost all numbering
systems that are easy to use are not future proof. The way of the world has always
been as data needs change, data gets updated.
That goes without saying but you are over analyzing the extremities of future
proofing when all that was really required here was a basic level of future proofing
however this was not really considered/implemented from the start (Not blaming
anyone for that) however 3 letters by 4 numbers would have covered almost all
situations and left us in a far better place than we are now!
Either way it’s a fine balance between future proofing but also not going over
the top with lengthy code references that are cumbersome to use and hard to remember.
but also started
with 3 letters too in order to give everything continuity with less chance of
abbreviations already being taken should future themes need to be considered/implemented
The set of 2-character abbreviations plus the set of 3-character abbreviations
is always greater than just the set of 3-character abbreviations, so using 2-character
abbreviations allows for _less_ of a chance of things already being used, not
more.
But is it necessary and how many themes are we expecting? Even similar abbreviations
can be worked around many times over with more than enough different combinations.
System limitations elsewhere will start to rear there head well before we run
out of 3 letter combinations for use with minifig themes.
In hindsight all minifigs should have been given 4 number digits
In hindsight, all simple to use numbering systems ever created for organizing
data should have been done differently. In other words, almost all numbering
systems that are easy to use are not future proof. The way of the world has always
been as data needs change, data gets updated.
That goes without saying but you are over analyzing the extremities of future
proofing when all that was really required here was a basic level of future proofing
however this was not really considered/implemented from the start (Not blaming
anyone for that) however 3 letters by 4 numbers would have covered almost all
situations and left us in a far better place than we are now!
The nice thing about hindsight is it is always 20/20.
The heart of this site is still the work of one lone individual. He was an extremely
talented individual with great foresight on many things, but one person can only
do so much. That is why he had volunteers helping him to create the data behind
the site. Unfortunately, those volunteers did not have any standards to go by
and made them up as they went along. That is pretty typical for a fledgling business.
Either way it’s a fine balance between future proofing but also not going over
the top with lengthy code references that are cumbersome to use and hard to remember.
Definitely.
but also started
with 3 letters too in order to give everything continuity with less chance of
abbreviations already being taken should future themes need to be considered/implemented
The set of 2-character abbreviations plus the set of 3-character abbreviations
is always greater than just the set of 3-character abbreviations, so using 2-character
abbreviations allows for _less_ of a chance of things already being used, not
more.
But is it necessary and how many themes are we expecting? Even similar abbreviations
can be worked around many times over with more than enough different combinations.
System limitations elsewhere will start to rear there head well before we run
out of 3 letter combinations for use with minifig themes.
I agree, but the 2-character abbreviations were set in stone from the beginning
(e.g. sp* [Space], sw* [Star Wars], etc.) and many minifigures were added over
the years with 4+-character abbreviations (e.g. frnd* [Friends], coltlbm* [The
LEGO Batman Movie Collectible Minifigures], etc.). We definitely try to keep
it to three to make things easier. However, there was never a standard for how
it was done, and I can't say if there will ever be one.
Canada, Alberta
United Kingdom, England
USA, Missouri
France, Provence-Alpes-Côte d'Azur
Netherlands, Gelderland
