-
Notifications
You must be signed in to change notification settings - Fork 794
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
Stardew valley: Add Trap Distribution setting #4601
base: main
Are you sure you want to change the base?
Stardew valley: Add Trap Distribution setting #4601
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the comments on the weights
parameter really need to be addressed, as this probably hit the performances a lot because of the loop. The potential caching issue in the tests needs to be validated as well. The rest is pretty minor.
Co-authored-by: Jouramie <[email protected]>
Co-authored-by: Jouramie <[email protected]>
…ke updating easier
… changed the default weight to 100
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just nitpicking, LGTM
What is this fixing or adding?
I originally wanted to put this in 7.x.x, but I figured out a decent way to make this work without being a breaking change in the mod. So in the spirit of making smaller, more incremental PRs, I decided to submit it as is.
This adds an option that allows users to specify a distribution for traps (assuming they enabled traps at all). They can use it to disable certain traps, or change how many they'll get of each.
As OptionDict() doesn't work on webhost, this is a yaml-only setting. If it ever gets added to webhost, I added it to groups properly and it'll work day1.
This only impacts the chances of rolling each trap. In practice, there will still be variation.
Lastly, to make this work, I had to do a refactor. Our class
items.py
has been split into twoitem_classes.py
anditem_creation.py
. This is to break up a circular dependency, where item_creation needs options, but now the options need the item_classes to build the Schema for this option.How was this tested?
Added some tests specifically for this, but since the feature is inherently random, the test cannot have 100% success rate. It is always possible that a freak seed ends up generating many of a trap that was requested with low odds, for example.
So I locked these tests behind one of our flags that makes it not run in the github pipeline, only with our specific local run configs. This way, the rare failure won't bother anyone except us.
I also generated a couple seeds with various odds to see the number of resulting traps matching the expected ballparks.