biodreamer

Build result differ between logged in and logged out when using a single set as source

Recommended Posts

If I run the exact same build query "1551-1" when logged in, I get a different result than if I am logged out. This is  not because of what I have in my Ignore List. I have cleaned that and only have a few keychains in there.

It looks like it ignores all my owned sets in the query even if the checkbox isn't checked for that. 

Share this post


Link to post
Share on other sites
1 hour ago, biodreamer said:

If I run the exact same build query "1551-1" when logged in, I get a different result than if I am logged out. This is  not because of what I have in my Ignore List. I have cleaned that and only have a few keychains in there.

It looks like it ignores all my owned sets in the query even if the checkbox isn't checked for that. 

Please check the complete URLs from your address bar for both logged in and logged out searches.  There is probably some difference between them because of your default settings when you are logged in.

Share this post


Link to post
Share on other sites

Out of curiosity, I ran the same query as you while I was logged in and got the results you list as being logged out. So, while I don't know what the cause is and will leave that for smarter minds to figure out, I can say that this problem isn't universally happening.

Share this post


Link to post
Share on other sites

@biodreamer Note the difference where it says 500 results found.  Logged in you are ignoring 15 sets from the list.

I got the same results logged in as I did as a visitor because I have no sets in my Ignore Sets list.

@Retrieverfalcon  Can you verify you have no sets in your Ignore Sets list?

Share this post


Link to post
Share on other sites
Posted (edited)

The set that are missing while being logged in are sets I have marked "owned" and is in one of my set lists available for builds, just not used in this query, neither do I tell it to skip sets I own.

I usually do use this setting, so I haven't noticed this bug earlier.

Edited by biodreamer

Share this post


Link to post
Share on other sites
2 hours ago, biodreamer said:

The set that are missing while being logged in are sets I have marked "owned" and is in one of my set lists available for builds, just not used in this query, neither do I tell it to skip sets I own.

I usually do use this setting, so I haven't noticed this bug earlier.

It is because of Your Settings.  If you look at the items on your ignore list, most of them have a 3001 in the inventory.  There is a 3001 in 1551-1.  In your Search you are choosing to look for 1 of any color of 3001.  The build function will not display an ignored set with a 3001 no matter what color it is.

What do you do with the check boxes on this screen?  build.thumb.jpg.5f79d97e05fa98824b4654ed520caa26.jpg

Share this post


Link to post
Share on other sites

That is the reason why I have them in ignore list. because a keychained 3001 is not the same part as 3001 imo. and I don't want them to show up in every result. I have the checkboxes the same on both queries both logged in and logged out. same goes for glued minifigs, don't want them if they can't be picked apart.

The checkbox are as following:

image.png.a44366559f511bf985d1846b57103c8e.png

image.png.34b05f928bafc464360ecb98fabdef01.png

image.png.685019062442ebe40a8368b5c79a483e.png

Share this post


Link to post
Share on other sites

just so you know there is 3001 in the sets in the search result. both ducks sets has them and you can clearly see the 3001 in store employee.

Like I said ALL missing sets are sets I Own, that is a bug unless I check the "Include Set I own from My Set Lists marked as Non-Buildable" which I don't in this case.

That checkbox feature is broken and always active now! (since I don't own any sets from the system perspective when I am logged out I get the full result.

Share this post


Link to post
Share on other sites

for the key chain why not make a new mold part entry for it. to reflect the changes between a 3001 and one with key chain attachment. I am sure I am not the only one bugged by those entries.

Share this post


Link to post
Share on other sites
On 4/13/2019 at 3:20 PM, thea said:

Can you verify you have no sets in your Ignore Sets list?

I actually have 269 sets in my "Ignore Sets" list. Personally, I don't see a need to "build" sets of bulk bricks so I tend to exclude those. 

I don't think the issue has anything to do with the ignore list at all.

Unlike @biodreamer, I don't have any of the set's in question in my own lists so that may have been why my initial test matched his logged out version. However, I ran a quick experiment and added one of the sets, the Duck from the first row of results, to a temp set list and I think I've tracked down the precise bug he's seeing. 

If my temp set list including the Duck is marked unbuildable (that is, the checkbox next to it in My Set Lists in unticked), the Duck does not show up in biodreamer's query. This is as expected since I'm not telling the system to include sets I own but have marked on unbuildable lists. If I toggle that build setting option (including sets in own for sets list marked as unbuildable), the Duck is included in my results. Again, as expected. However, if I toggle my temporary set list to be marked as buildable (checked in My Sets), the toggle box doesn't matter at all and I never see the Duck in my results. This appears to be where the bug shows up.

The top of biodreamer's settings that he posted show not including 1359 of his 1437 sets in My Sets. I suspect if he checks the set lists that contain those 1359 sets, he'll find all the missing results somewhere in those lists. 

Based on these results, I have to agree with biodreamer that a bug (or at least a missing feature) exists here. The desired query is "what sets can be build from the type of parts in 1551-1?" The results shouldn't care whether I already own (marked buildable or not) them in my own set lists. 

The problem isn't with ignored sets or the &inc_owned toggle. In fact, the problem isn't in the URL string at all which is why his examples logged in or logged out were the same URL but different results. It appears the algorithm is factoring the Set List "buildability" check box into account for more than just opting sets out of the 'include X of Y' checkbox at the top of the Build screen as potential part sources. It is also treating these sets as excluded from the search results which isn't the intended outcome.

Share this post


Link to post
Share on other sites
8 minutes ago, Retrieverfalcon said:

It appears the algorithm is factoring the Set List "buildability" check box into account for more than just opting sets out of the 'include X of Y' checkbox at the top of the Build screen as potential part sources. It is also treating these sets as excluded from the search results which isn't the intended outcome.

I had reached the same conclusion just a little while ago.  If you remove the check for the inc_owned, you are basically telling the build function to Ignore those sets completely, not just their parts.

Share this post


Link to post
Share on other sites
6 minutes ago, thea said:

I had reached the same conclusion just a little while ago.  If you remove the check for the inc_owned, you are basically telling the build function to Ignore those sets completely, not just their parts.

Actually, I don't think the inc_owned is factoring in. In fact, if the set in question is on a Set List that is ticked off under My Sets, inc_owned works exactly as expected. And by definition, inc_owned doesn't apply to Set Lists which are ticked on. But you're right - it's ignoring the set's completely not just as a potential part contributor. 

I should not I haven't tested the edge case if two copies of a set are in your My Sets, one ticked on and one ticked off. I'll leave that for others with access to the actual algorithm to figure if it matters.

Share this post


Link to post
Share on other sites

It was a bug, it wasn't applying the include sets I own filter consistently. Fixed now.

I also added an extra filter option to include ignored sets in there, to help with any future debugging :)

Share this post


Link to post
Share on other sites
On April 14, 2019 at 2:59 AM, biodreamer said:

for the key chain why not make a new mold part entry for it. to reflect the changes between a 3001 and one with key chain attachment. I am sure I am not the only one bugged by those entries.

Yes it is annoying, but...

The brick comes out of the mold correctly, so there is no mold variation.  Technically when you buy a keychain with a 3001, you are buying a damaged brick.

Share this post


Link to post
Share on other sites
7 minutes ago, thea said:

Yes it is annoying, but...

The brick comes out of the mold correctly, so there is no mold variation.  Technically when you buy a keychain with a 3001, you are buying a damaged brick.

so the old base plates that where cut into right size would be a gigantic plate? if the damage is made on purpose on the  factory side, they should warrant a mold imo.

Share this post


Link to post
Share on other sites
7 hours ago, biodreamer said:

so the old base plates that where cut into right size would be a gigantic plate? if the damage is made on purpose on the  factory side, they should warrant a mold imo.

I agree with that. One of the main points of Rebrickable is to see what you can build with what you have. A part that you buy that can't be used to build because it was altered out of the box will just give you false positives and I don't see an upside to using this approach. I also have this problem with glued parts. For example, in this set:

https://rebrickable.com/sets/5004388-1/nexo-knights-intro-pack/#parts

It lists 3 parts that I will never be able to use because they are glued together with a key chain. I think in cases like that they shouldn't be listed as individual parts.

 

Share this post


Link to post
Share on other sites
3 hours ago, Vokhev said:

I agree with that. One of the main points of Rebrickable is to see what you can build with what you have. A part that you buy that can't be used to build because it was altered out of the box will just give you false positives and I don't see an upside to using this approach. I also have this problem with glued parts. For example, in this set:

https://rebrickable.com/sets/5004388-1/nexo-knights-intro-pack/#parts

It lists 3 parts that I will never be able to use because they are glued together with a key chain. I think in cases like that they shouldn't be listed as individual parts.

 

My view of the glued parts found on many key chains is that they should be categorized separately due to their lack of use in the build system and their false positive nature. However, not all keychains are glued and those which aren't should be inventoried as usable build bricks.in many ways these parts are no different that Junior-ized elements which are already given unique part numbers despite being composite molds of other existing parts.

The Set you picked to make your example, however, 5004388-1 is a poor choice. That set just has a messed up inventory with missing parts and erroneous information. I have submitted several part submissions and a CR to correct it which are pending with the admins.

Share this post


Link to post
Share on other sites
42 minutes ago, Retrieverfalcon said:

The Set you picked to make your example, however, 5004388-1 is a poor choice. That set just has a messed up inventory with missing parts and erroneous information.

If you say so. I used that example because I had commented on the problem when I first got the set and I was told it was normal for it to be inventoried this way.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now