| Discussion Forum: Thread 357553 |
|
 |
| | | Author: | Linse  | | Posted: | May 9, 2024 04:30 | | Subject: | BL part changes destroy valid XMLs | | Viewed: | 101 times | | Topic: | Help | |
|
| Hi guys,
sadly the process of changing and merging parts on Bricklink (BL) is going on
and on, which is in some cases good and in some very bad.
I am a MOC designer and doing MODs of existing MOCs. For those modifications
I normally provide Studio generated Bricklink wanted list XMLs next to my instruction
pdfs.
In the last months I received more and more emails that complain about those
XML files.
I always test those XMLs right after I create them by importing them into my
default BL wanted list. So I know the XMLs are valid and work on BL at the moment
I created them.
But the strange way (at least in my opinion) of changing the parts lib on BL
and the way the poor implemented XML importer works on BL, those XMLs are suddenly
invalid.
So I have to regenerate the XMLs or cause Studio and BL are not synchronized
on the part changes, I have to manually fix the XMLs. This means I have to spend
a serious amount of my spare time for something that should really not be my
task.
My question is, why does it have to work this way?
All other tools and platforms, like Rebrickable, are still able to import those
"invalid" XML files.
I would expect BL just sets the old part numbers to "deprecated" or adds
the old numbers as valid alternatives to the new ones. So the import tool can
automatically switch those parts to the new valid number while the import process
Or another simple solution, the import tool has a "whitelist" of those
old parts integrated. So if the part is not found in the BL database, it checks
the "whitelist" and if the part is found there it automatically converts
it to the new number.
Really strange that such a situation is reality in 2024 with all that AI around
us.
Kind regards
Joerg aka Linse
|
|
|
| | | | | |
| | | | | Author: | Stellar | | Posted: | May 9, 2024 05:30 | | Subject: | Re: BL part changes destroy valid XMLs | | Viewed: | 50 times | | Topic: | Help | |
|
| In Help, Linse writes:
| | Hi guys,
sadly the process of changing and merging parts on Bricklink (BL) is going on
and on, which is in some cases good and in some very bad.
I am a MOC designer and doing MODs of existing MOCs. For those modifications
I normally provide Studio generated Bricklink wanted list XMLs next to my instruction
pdfs.
In the last months I received more and more emails that complain about those
XML files.
I always test those XMLs right after I create them by importing them into my
default BL wanted list. So I know the XMLs are valid and work on BL at the moment
I created them.
But the strange way (at least in my opinion) of changing the parts lib on BL
and the way the poor implemented XML importer works on BL, those XMLs are suddenly
invalid.
So I have to regenerate the XMLs or cause Studio and BL are not synchronized
on the part changes, I have to manually fix the XMLs. This means I have to spend
a serious amount of my spare time for something that should really not be my
task.
My question is, why does it have to work this way?
All other tools and platforms, like Rebrickable, are still able to import those
"invalid" XML files.
I would expect BL just sets the old part numbers to "deprecated" or adds
the old numbers as valid alternatives to the new ones. So the import tool can
automatically switch those parts to the new valid number while the import process
Or another simple solution, the import tool has a "whitelist" of those
old parts integrated. So if the part is not found in the BL database, it checks
the "whitelist" and if the part is found there it automatically converts
it to the new number.
Really strange that such a situation is reality in 2024 with all that AI around
us.
Kind regards
Joerg aka Linse
|
Indeed that is a huge problem, sadly with the current tools within Bricklink
there no option, wish they updated the import to also match to alternate IDs.
For the time being your best option is to use the software Brickstore, import
the XML there and it will fix all the entries to match Bricklink, then you can
export as XML again.
|
|
|
|
|
|
|
Germany, Baden-Württemberg
Spain, Comunidad Valenciana