Custom Item Pool

[Alchav]

Adds custom_item_pool common option. Format currently is as follows:

  custom_item_pool:
    modify:
      Single Bomb: 1  # add one Single Bomb
      Blue Boomerang: -1  # remove one blue boomerang
    set:
      Rupees (100): 2  # set number of Rupees (100) to 2
    replace:
      Flute: Activated Flute  # replace all flutes with activated flutes
    no_defaults: False  # default False. If True, the entire item pool will be scrapped in favor of the numbers set in custom_item_pool

Currently lacks documentation.

[Jarno458]

Should probably have a Check that the total size of modified pool vs original pool to see if it's even going to work

If the new pool is smaller do you expect it to fill with get_filler_item_name?

What do you expect if people want to replace an item that was placed locked and thus is not in the current pool?

[Alchav]

Should probably have a Check that the total size of modified pool vs original pool to see if it's even going to work

If the new pool is smaller do you expect it to fill with get_filler_item_name?

What do you expect if people want to replace an item that was placed locked and thus is not in the current pool?

I want to have a way to check pool size and correct it, but personally I also want a way to bypass this. I play a lot of async games with my family and friends where I play several games at once and I like the idea of being able to take items out that are completely useless (lore tablets, 1up mushrooms, the 4 useless factorio techs, etc) from one game and then be able to add more items to another game.

[Jarno458]

I can see that be fun but that is probably something you want default off, as I can't see that ever working in community run games

[Alchav]

Now corrects item pool size (unless this option is turned off) and has documentation, but will have to be fixed when and if #638 is merged.

[Alchav]

Other than a few nit-picks, the biggest issue I have is that the function can generate more items than locations which affect others' seeds by making it possible for their filler items to appear in unplaced locations, which should never happen. If you affect your pool, it should only affect your game.

This is already possible in Archipelago by using plando_items with from_pool set to false, and there is in fact no way to then reduce the items in your pool to compensate.

[Berserker66]

Other than a few nit-picks, the biggest issue I have is that the function can generate more items than locations which affect others' seeds by making it possible for their filler items to appear in unplaced locations, which should never happen. If you affect your pool, it should only affect your game.

This is already possible in Archipelago by using plando_items with from_pool set to false, and there is in fact no way to then reduce the items in your pool to compensate.

Then I guess custom item pool should be locked behind a host opt-in option too.

[Alchav]

I think I have an idea on how to get what I want (to be able to reduce the items in one of my games and add extra items to another) in a way that can't be abused. I'll have the item pool correction always happen, but allow you to set up a pool size correction link with other players and these games will have their item pools corrected as a group

[alwaysintreble]

Other than a few nit-picks, the biggest issue I have is that the function can generate more items than locations which affect others' seeds by making it possible for their filler items to appear in unplaced locations, which should never happen. If you affect your pool, it should only affect your game.

This is already possible in Archipelago by using plando_items with from_pool set to false, and there is in fact no way to then reduce the items in your pool to compensate.

Then maybe this should be fixed by generation ensuring a player's itempool == the player's location count since you're already pulling the full world itempool here seems like a good time to fix this.

[Alchav]

Other than a few nit-picks, the biggest issue I have is that the function can generate more items than locations which affect others' seeds by making it possible for their filler items to appear in unplaced locations, which should never happen. If you affect your pool, it should only affect your game.

This is already possible in Archipelago by using plando_items with from_pool set to false, and there is in fact no way to then reduce the items in your pool to compensate.

Then maybe this should be fixed by generation ensuring a player's itempool == the player's location count since you're already pulling the full world itempool here seems like a good time to fix this.

Since this is happening before pre-fill, there's no easy way to check to ensure an item pool is the right absolute size. For example in LTTP there is a large difference between number of items in the pool vs location count at this point in generation.

I think a better solution would be to remove the from_pool option from item plando and remove the possibility of creating extra items there, since they can just add extra items to the pool here if they want (which is before item plando is run)

[Alchav]

So I read through the most recent changes. We still have the issues where with certain settings, like so below, would allow the chance for items to become not accessible for worlds that did not modify their own item pool.

Rogue Legacy:
  custom_item_pool:
    set:
      Death Defiance: 30
    use_defaults: false

Unplaced items(143): [5000 Gold (Test RL), Down Strike Up (Test RL), 3000 Gold (Test RL), Death Defiance (Test RL), 
Triple Stat Increase (Test RL), Rupees (20) (Test ALTTP), Retaliation Runes (Test RL), Crit Damage Up (Test RL), Triple 
Stat Increase (Test RL), Rupees (20) (Test ALTTP), Bombs (10) (Test ALTTP), 5000 Gold (Test RL), Grace Runes (Test RL), 
3000 Gold (Test RL), Single Arrow (Test ALTTP), 1000 Gold (Test RL), Triple Stat Increase (Test RL), 5000 Gold (Test 
RL), Triple Stat Increase (Test RL), 1000 Gold (Test RL), Royal Blueprints (Test RL), 3000 Gold (Test RL), Haggling 
(Test RL), Crit Damage Up (Test RL), 1000 Gold (Test RL), Bombs (3) (Test ALTTP), Bombs (3) (Test ALTTP), Progressive 
Knaves (Test RL), Death Defiance (Test RL), Silver Blueprints (Test RL), 1000 Gold (Test RL), Mana Cost Down (Test RL), 
Rupees (300) (Test ALTTP), 1000 Gold (Test RL), Rupees (50) (Test ALTTP), 5000 Gold (Test RL), Triple Stat Increase 
(Test RL), Death Defiance (Test RL), 5000 Gold (Test RL), 5000 Gold (Test RL), 3000 Gold (Test RL), 5000 Gold (Test RL),
Death Defiance (Test RL), Retribution Blueprints (Test RL), 1000 Gold (Test RL), Rupees (20) (Test ALTTP), Rupees (20) 
(Test ALTTP), Rupees (20) (Test ALTTP), Triple Stat Increase (Test RL), Rupees (20) (Test ALTTP), 5000 Gold (Test RL), 
5000 Gold (Test RL), 1000 Gold (Test RL), Arrows (10) (Test ALTTP), Bombs (3) (Test ALTTP), Progressive Liches (Test 
RL), Death Defiance (Test RL), Ranger Blueprints (Test RL), Haste Runes (Test RL), Triple Stat Increase (Test RL), 3000 
Gold (Test RL), 3000 Gold (Test RL), 1000 Gold (Test RL), Dragons (Test RL), Rupee (1) (Test ALTTP), Rupees (20) (Test 
ALTTP), Progressive Shinobis (Test RL), Blood Blueprints (Test RL), Triple Stat Increase (Test RL), Death Defiance (Test
RL), Bombs (3) (Test ALTTP), Death Defiance (Test RL), Dragon Blueprints (Test RL), Balance Runes (Test RL), Rupees (20)
(Test ALTTP), Rupees (20) (Test ALTTP), 1000 Gold (Test RL), 3000 Gold (Test RL), Arrows (10) (Test ALTTP), Crit Chance
Up (Test RL), Invulnerability Time Up (Test RL), 1000 Gold (Test RL), 5000 Gold (Test RL), Rupee (1) (Test ALTTP), Death
Defiance (Test RL), 1000 Gold (Test RL), 1000 Gold (Test RL), Progressive Mages (Test RL), 3000 Gold (Test RL), Death Defiance (Test RL), 5000 Gold (Test RL), Triple Stat Increase (Test RL), Bombs (3) (Test ALTTP), 3000 Gold (Test RL), 
Death Defiance (Test RL), 3000 Gold (Test RL), 5000 Gold (Test RL), 1000 Gold (Test RL), Arrows (10) (Test ALTTP), 
Rupees (5) (Test ALTTP), Rupees (20) (Test ALTTP), Arrows (10) (Test ALTTP), 5000 Gold (Test RL), Triple Stat Increase 
(Test RL), Sage Blueprints (Test RL), 5000 Gold (Test RL), Rupees (20) (Test ALTTP), Rupees (20) (Test ALTTP), 3000 Gold
(Test RL), Progressive Spellthieves (Test RL), Vault Runes (Test RL), Triple Stat Increase (Test RL), Crit Chance Up 
(Test RL), Triple Stat Increase (Test RL), 3000 Gold (Test RL), Potion Efficiency Up (Test RL), Progressive Barbarians 
(Test RL), Sky Runes (Test RL), 3000 Gold (Test RL), Rupees (20) (Test ALTTP), 5000 Gold (Test RL), Progressive Miners 
(Test RL), Death Defiance (Test RL), Triple Stat Increase (Test RL), Triple Stat Increase (Test RL), 5000 Gold (Test 
RL), 3000 Gold (Test RL), Death Defiance (Test RL), Arrows (10) (Test ALTTP), Arrows (10) (Test ALTTP), Rupees (5) 
(Test ALTTP), 3000 Gold (Test RL), Sprint Runes (Test RL), Bombs (3) (Test ALTTP), Arrows (10) (Test ALTTP), 3000 Gold 
(Test RL), Arrows (10) (Test ALTTP), 1000 Gold (Test RL), Rupees (5) (Test ALTTP), 5000 Gold (Test RL), 1000 Gold (Test 
RL), Triple Stat Increase (Test RL), 5000 Gold (Test RL)] - Unfilled Locations(0): []

A suggestion I would have is since you are pulling the item pools for each world, is to either remove use_defaults and always assume it to be true or just count the number of items in the pool and generate enough filler so the item pool matches the count in the world. (Although, I'm not a fan of that second approach because it can cause generation issues or impossible scenarios if a rule cannot take it into account)

Also this should also include a conditional to prevent custom_item_pool from being used if it is not enabled in the host.yaml as it does make generation longer and especially if there is no way to ensure that it does not affect accessibility for other worlds without any custom_item_pool settings.

In addition there are some performance or runtime concerns that should be addressed or at least elaborated on.

It was not affecting any item counts for items not specified in custom item pool. This has been fixed.

[ThePhar]

Can we still have this lock behind plando settings or a separate host.yaml setting? Definitely should be opt in regardless since it will increase generation time.