-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
add eoc effect and condition, that searches weighed amount of items in your inventory #75631
Conversation
So, if I understand it correctly, the code consumes items in the listed order until the percentage reaches 100 (or 1, technically). returning with This is an extreme example, of course, but I think it illustrates the point that the order really matters, and the "conversion ratios" between items do as well. I don't know if there is any reasonable solution to the general problem, but I'd suggest consumption of everything from a single stack should be the preferred option, i.e. if any single category provides everything required, that category should be selected. This would require the logic to change a little by having the tallying of items done on a per item basis (and you can then use the count at that step, rather than percentages). Once you've tallied what you've got available you can then use logic to decide what to consume (which I suggest would include selection of a completed single entry, if available as the preferred alternative). This would also allow for further refinement of the selection logic without affecting the tallying if desired at a later time. I can't see any general recommendation for how to select the order of entries in such a selection (for documentation purposes). On the one hand, you'd want the heavier entries (the ones with the lowest counts) first to reduce over consumption, but on the other hand, you'd also want things to divide nicely so you end up with exactly 100% rather than overshooting. |
What you say is something i am aware of, but i thought i could solve it by sorting the list (either in json, shoving the most heavy stuff first, or, better, in the code, by sorting a vector from smallest count to biggest one) I agree having an ability to pick which exactly items you want to give would be cool, but i don't feel myself confident to implement it |
The problem with having the code determine the order is that it removes the ability of the JSON writer to select other orders deemed more suitable to their particular situation. However, I agree that a code choice removes the risk of uninformed JSON writers inadvertently making bad orders. |
c010687
to
9aff6b7
Compare
It's online and working, but i need to test it first. Anyone happen to have tacoma save file? |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
If you made one can you load it up in an issue labeled "Debug Save Files"? I'll mark it so it won't stale. |
Where i should post it, again? I think i still have it around, albeit it's Karol save frok and 2022, so it has few errors popping at the start |
Summary
None
Purpose of change
Fix #74726
Fix #71215
Describe the solution
The idea is to have the condition like this:
and under the hood the game checks how much of each item user has, as percentage, so, for example, having 5 blanket and 10 blanket_fur would both count as 50%, which would result in 100% total and condition returning "true"
Effect does the same thing, but instead of checking items, it just consumes them
Testing
save file used to test thing
Mainsave-trimmed.tar.gz