Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Having a progressive item in starting inventory remove all other instance from item pool #178

Closed
neocerber opened this issue Mar 29, 2024 · 4 comments

Comments

@neocerber
Copy link

What happened?

While doing other stuff, I discovered that, in the current main (25/03/2024, 1d45125), adding a Progressive item in the starting inventory remove all its instance from the pool for SC2.

What I did:

  • checkout main
  • Generate a game with default template Starcraft 2.yaml.txt, except starting
    with
    • Progressive Stimpack (Marine): 1
    • Progressive Stimpack (Marauder): 1
    • Progressive Protoss Air Armor: 2
  • Upload the game generated.
  • Use /collect

Results?

  • Everything is available, except
    • No Marine stimpack
    • No Marauder stimpack
    • No Protoss Air Armor

What were the expected results?

Having everything including the two Marine stimpack, the two Marauder stimpack and the three Protoss Air Armor.

Note: If I correct the Webtracker to show starting inventory, than I see one Marine stimpack, one Marauder stimpack and two Protoss Air Armor. So, it is really that the other instances are removed.

The problem seems to be in allowed_quantity(), where
if name in excluded_items or (...) does not take into account that some items have quantity. So, if a Progressive item is in starting inventory, pew pew, all instance of that item is not in the pool!

(Might have similar problem with other cases)
I do not have a clean solution atm since allowed_quantity() is used elsewhere and I am not confident enough that I won't break things.

Software

Local generation

@MatthewMarinets
Copy link

This is likely fixed by #192, but probably better to check.

@neocerber
Copy link
Author

@MatthewMarinets I re-runned the test once and the faulty behavior was not present. Thus, it seems to be fixed. Shall I close the Issue now or should we wait for sc2-next to be in AP main?

@MatthewMarinets
Copy link

Shall I close the Issue now or should we wait for sc2-next to be in AP main?

Probably more a question for @Ziktofel. It likely comes down to how likely it is someone else bumps into this problem on main, wants to report it on gh, but checks open issues but not closed ones. I think that's unlikely (someone will likely post in discord first and get told it's fixed on beta), so I'd personally say to close it.

@Ziktofel
Copy link
Owner

Here, the bugs shall be closed when solved in sc2-next as we've already dealt with the problem and it will be solved by a next feature release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants