Skip to content

fix item_rewards.py#19

Open
wrjones104 wants to merge 2 commits into
beauxq:ff6wcfrom
wrjones104:ff6wc
Open

fix item_rewards.py#19
wrjones104 wants to merge 2 commits into
beauxq:ff6wcfrom
wrjones104:ff6wc

Conversation

@wrjones104

Copy link
Copy Markdown

Skip "Empty" items and handle missing item qualities

This commit updates the item_rewards.py file to address two issues:

  1. It skips processing for items named "Empty".
  2. It ensures that items not present in chest_item_tiers are handled by adding them with a default quality level.

…ities

This commit updates the `item_rewards.py` file to address two issues:
1. It skips processing for items named "Empty".
2. It ensures that items not present in `chest_item_tiers` are handled by adding them with a default quality level.
@wrjones104

Copy link
Copy Markdown
Author

See https://discord.com/channels/731205301247803413/1022545979146252288/1520022989914112130 and surrounding comments for context.

Comment on lines +142 to +143
if item_name == "Empty":
continue

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If "Empty" is in an event location, doesn't that still need a dialog?
The game displays a dialog when you do the event, doesn't it?

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks to me like we still want to process the "Empty"s.
The only problem was "Empty" not being in the qualities

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, agreed - fixed in next commit

@beauxq

beauxq commented Jul 4, 2026

Copy link
Copy Markdown
Owner

Thank you for investigating and developing a fix for this bug.

It seems like some of these changes have the goal of avoiding crashes. I think the goal of avoiding bugs is more important than avoiding crashes. And avoiding crashes is actually counter-productive - it makes bugs more likely.
If there is a bug in the code, it's better if it crashes, because that makes it easier to find and fix the bug. If it doesn't crash, it's more difficult to find and fix the bug.

For example:

        if "Cursed Shld" in Rom.item_name_id:
            qualities[Rom.item_name_id["Cursed Shld"]] = 1

"Cursed Shld" should always be in Rom.item_name_id - If it's not, it's a bug.
But that bug becomes more difficult to find because it doesn't crash.

Also, when making a change with a pull request, the normal practice is to use a different branch for each pull request. (And often, the branch is deleted after the pull request is merged.)
The process is described in many places. Here are some examples:
https://docs.github.com/en/get-started/using-github/github-flow
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

It makes it a little more difficult for me when you use the same branch for multiple different pull requests.

I've made a new PR from a new branch with how I would address this problem.
#20
Will you take a look and tell me what you think?

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

Successfully merging this pull request may close these issues.

2 participants