Rubik's CBM inventory refreshes WAY too fast

[FlyingVolvo]

Describe the bug

Rubik currently provides what is in effect access to an immense amounts of CBMs because his trade inventory refreshes every time you ask him to assist with an operation.

Steps to reproduce

1. Unlock access to Rubiks CBM assistance
2. Perform a minor operation
3. Watch his trade inventory get new items

Expected behavior

For it not to refresh with new CBMs every single operation he helps with.

Screenshots

No response

Versions and configuration

• OS: Windows
  • OS Version: 10.0 2009
• Game Version: 0d7276f [64-bit]
• Graphics Version: Tiles
• Game Language: English [en]
• Mods loaded: [
  Dark Days Ahead [dda],
  No Fungal Monsters [No_Fungi],
  Bionic Professions [package_bionic_professions],
  SpeedyDex [speedydex],
  Stats Through Skills [StatsThroughSkills],
  Original Drug Names [OG_Drugs]
  ]

Additional context

No response

[Maleclypse]

@I-am-Erk tagging to make sure you see this.

[FlyingVolvo]

#53057 magnifies this issue even further because after a handful of operations it looks like this

[estebandellasilva]

#53057 magnifies this issue even further because after a handful of operations it looks like this

No Cardbord Boxes? Blasphemer - i remember my rubik having stacks of cardbordboxes lying around it was trashhell ... and he got more every time

[I-am-Erk]

Probably missed an instance of a timer variable check. I'll try to get some time to have a look

[Nerezza]

I just added new information to #54695 that I believe is also relevant to this.

Notably: Rubik is deleted every time you start a conversation with them, and a new one is spawned in a turn after the conversation ends. This new Rubik seems to hold the new CBMs being added to the stock, while the rest of the stock is the leftover everything the old Rubiks dropped on the ground, and whatever's stocked in the shelves.

For some reason whatever's deleting Rubik is tied to the bug that's teleporting the player and causing fall damage.

[Nerezza]

So I've done some investigation and this bug is actually the reason #54695 was triggering every time we talked to Rubik.

Inside exodii_merchant_talk.json it appears this block was being triggered every time we spoke to Rubik:

      {
        "//": "Every week, add some stuff to the shop based on your current trust.",
        "condition": {
          "and": [
            { "u_has_faction_trust": 1 },
            { "not": { "u_has_effect": "u_exodii_interaction_timer_long" } },
            { "u_has_trait": "CBM_Interface" }
          ]
        },
        "effect": [ { "mapgen_update": "tier1_CBM_shop_update", "om_terrain": "exodii_base_x0y2z1" } ]
      },

I'm still trying to work out why this is triggering its mapgen update, I'm hoping someone that knows flow control in json files can look this file over for bugs.

Edit just a bit later: I checked player vars and u_exodii_interaction_timer_long is applied so the "and" should be returning false.

[bombasticSlacks]

As posted on the discord:

I'm guessing its because "u_exodii_interaction_timer_long" is sentineled
so it only happens once, so after the first 7 days of the effect you then never get it on talking to Rubik again. This is a problem since it is the blocker for the shop refreshes.

It should probably be moved to a user time variable since I don't know what order all those speaker effects are applied in. I feel like if it was non sentineled it would apply and then the further conditionals to refresh would fail always.

The issue with falling is being fixed by Ramza in #55021 and is related to any mapgen updates.

[Nerezza]

As posted on the discord:

I'm guessing its because "u_exodii_interaction_timer_long" is sentineled so it only happens once, so after the first 7 days of the effect you then never get it on talking to Rubik again. This is a problem since it is the blocker for the shop refreshes.

It should probably be moved to a user time variable since I don't know what order all those speaker effects are applied in. I feel like if it was non sentineled it would apply and then the further conditionals to refresh would fail always.

The issue with falling is being fixed by Ramza in #55021 and is related to any mapgen updates.

Thank you for your input, it helped me work out how the speaker effects were written.

Since speaker effects are an array I figured they were executed by going through their index beginning-to-end and it appears I was correct because Rubik's restocking properly now. I'm pretty sure that if this bug hadn't existed, Rubik's CBM restocking actually would not have triggered with the order the speaker effects were in before I poked around in the json to fix this bug.