So I was finally bugged enough times to put the old Light Gray/Dark Gray colors back in :)
First an explanation of how we got here. When I was first experimenting with how the site would work and if it could even be done, I noticed that the Light Gray parts had stopped being produced around 2003 and were replaced by Light Bluish Gray parts. Similarly for Dark Gray. 2003 was during my dark ages period so I hadn’t noticed it earlier! This was going to make it nearly impossible for a pre-2003 set to get a high match with any post-2003 set, causing much frustration for me.
I came up with the idea of equating similar colors. This was to improve the % of matching parts between sets during the build calculations. Whenever the algorithms came across an old color it would simply use the new color instead. I set this up for LG-LBG and DG-DBG only, thinking if I came across any other examples I could do the same thing.
After all, they look similar right?
Light Gray and Light Bluish Gray:
Dark Gray and Dark Bluish Gray:
This made a nice improvement in the average % matching scores during my testing so I decided to keep it.
The problems started once I introduced the My Parts feature allowing people to store their loose parts. Little did I realise the passion of the LEGO community in maintaining a pure record of their parts!
There are 2710 sets that have had Light Gray or Dark Gray changed to Light Bluish Gray or Dark Bluish Gray, and 125761 parts in total that potentially need changing.
I had two options:
1. Manually update the table data. The side effect of making Rebrickable’s complex calculations fast is that there is a lot of redundant and pre-calculated data spread out over many tables. So making a change in one place requires changes in several other places, and due to the layers of computation already done on the data makes this extremely difficult. It is a huge problem to solve with a high chance of buggering it all up.
2. Use the existing code that does these part/color transformations and re-apply it without the color mappings. This will cover nearly every scenario except for some early site problems which didn’t keep track of every change very well. So other than a few sets that were manually updated over a year ago, most sets should turn out correct. However this option is very resource intensive as every set that is updated needs to perform a lot of repeated calculations, and will take a long time to get through all the affected sets.
I looked into option 1 for a while to try and come up with a quick fix, but gave up eventually. So, I have started implementing option 2 already. I have the list of 2710 impacted sets and will be re-processing each of them one by one over a period of weeks.
You should start to see some parts show up in the old colors already, and in the coming weeks it will become more complete.
As a result of the update, any build calculations performed using the “Exact” color matching will start to produce different (probably worse) results than previously. Any calculations performed using the “Close” or “Ignore” color matching will have no difference as the old and new colors are considered close in the algorithms.
In addition to fixing the existing data, the code for mapping the old to new colors has already been disabled. This means you can import the old colors into your own MOCs and My Parts list without them being automatically converted.
I will provide an update when it is complete!
Update: It’s done.