[Enhancement] Consider the next action when calculating number of dunks/quenches

[izinman]

Same with the other issue I've added - I'm interested in implementing this as long as someone will review and merge it. I'm fairly confident this one applies to all metals and smithing levels.

Currently, the algorithm for suggesting dunks/quenches will get you close to the correct side of the temperature range if you're starting off, but if you only have a couple actions left, it will just tell you how many you need to complete the current action. However, in cases where the following action will require the same heating actions (i.e. heating or cooling) as you need to finish your current task, it would be slightly more optimal to continue the heating action until you get closer to the target heat for the next action, not just completing the current action, to take advantage of the heating "streak" effect.

Let me give an example to illustrate. Here's what the current behavior will do. Let's say I have 3 actions remaining on the grindstone, and my next action is polish. When I go to dunk, it will suggest the minimum number of dunks to finish the current action - let's say that's 2 for this example. 2 dunks will put me in the middle-top of the grindstone temperature band, so that when I finish the grindstone, I will be nearly at the top of the grindstone temperature band. I'll have to go back to the waterfall for my polishing task that's next, and I'm likely to overshoot the top of the polish range since I'm far from it, so I'll have to use maybe 10 dunks and end up 15% of the way into the polish temperature band rather than right at the top.

Instead, imagine the algorithm considered that the next task is polish, and suggested the number of dunks to get near the bottom of the grindstone temperature band before finishing the current grindstone task. We will have to make 2 trips to the waterfall either way, but taking advantage of the accelerating quench on our first trip to the waterfall will get us closer to the target in the first place, and probably reduce the overall number of quenches between the two waterfall visits by 1 or 2, and get us closer to the top of the polish temperature band.

It's a minor enhancement but would be a nice way to slightly optimize the suggested temperature action.

[jack0lantern]

I had this exact thought. I'm down to test what you put out. I'm not a contributor though, so I cannot merge.

[izinman]

I appreciate that. I've found the relevant logic - where GoalHeat is assigned in HeatActionStateMachine, in calculateEstimates starting on line 114 - and the changes would be quite simple. Effectively, I'd factor out existing logic to a helper that takes into account the following stage. However, I'm concerned that given the lack of activity in this repo, a pull request wouldn't be merged, so I'll hold off until I hear a response from one of the repo admins.

[pwatts6060]

You can go ahead with it, but please add this option as another config that can be toggled so the plugin can work as is as well.

[izinman]

Thanks for the response! I'll get to work and hopefully have a PR out for review in the next week or two, with the updated algorithm conditional on a config option.

One other thing - I have a slight concern about testing a development plugin using my main account, and I'd rather not buy a bond for an alt just for the sake of testing the plugin. Is it generally considered that runelite plugin developers are safe to use main accounts to test plugins (obviously, assuming those plugins are clearly within guidelines and not cheating)? I'd hate to get my main banned for this. Thanks!

[pwatts6060]

You won't get banned, don't worry.