Closed krogenth closed 1 year ago
Opening for review, but I do have several questions/concerns in terms of what intended behavior we want to have happening.
Start Fans (Airship)
, the first console is never deactivated until the proper code is inputted to the second console, since the player is intended to be able to go back and review the given code. This currently means the pathfinding will keep the first console as a task, even after it is used. This could potentially keep the AI locked at the first console until a meeting or other event pulls them away hoping to complete the task there.Put Away Pistols/Rifles (Airship)
, do we care about how quickly the initial guns are picked up? The closest I can think of to try and limit this is to go through the IMinigameOpener.ShouldOpenConsole
and give a cooldown for collecting the next gun. The current rapid-fire clicking ends up causing the Interactionshandler.UseConsole
to retrieve a null
task.For tasks like Start Fans (Airship), the first console is never deactivated until the proper code is inputted to the second console, since the player is intended to be able to go back and review the given code. This currently means the pathfinding will keep the first console as a task, even after it is used. This could potentially keep the AI locked at the first console until a meeting or other event pulls them away hoping to complete the task there.
Once the code has been viewed, ShouldOpenConsole should return false for the first console.
For tasks like Put Away Pistols/Rifles (Airship), do we care about how quickly the initial guns are picked up? The closest I can think of to try and limit this is to go through the IMinigameOpener.ShouldOpenConsole and give a cooldown for collecting the next gun. The current rapid-fire clicking ends up causing the Interactionshandler.UseConsole to retrieve a null task.
This will require implementing some sort of memory in the task. Since minigame solvers are singletons, then we can't store anything in their class. This is a design oversight, I did not expect us to need memory for tasks.
My implementation of memory was using the task's own Data
, you can see it in #33 with ResetBreakersSolver.cs
Although if we have many tasks that require memory, it might be a better idea to change the minigame solving system so it supports that.
This will require implementing some sort of memory in the task. Since minigame solvers are singletons, then we can't store anything in their class. This is a design oversight, I did not expect us to need memory for tasks.
I see, I will need to change StartFansSolver.cs
in this case. Going through practice runs it worked fine, but looks to break in local lobbies at least.
Although if we have many tasks that require memory, it might be a better idea to change the minigame solving system so it supports that.
The only games within this PR that benefit from memory is StartFansSolver.cs
(solution only visible from first console from what I can see) and PutAwayWeaponsSolver.cs
(to avoid rapid execution of initial pickup).
Correct me if I am wrong, but I think that you cannot open the second part of Start Fans until you've opened the first part. You can use this state to check whether or not the first console should be opened.
Yes, the issue shouldn't be so much which console it use, but the code to input. I'll double check the data available, but as far as I was able to see before, I could only view the code through the StartFansMinigame.CodeIcons
list at the first console. So I'd need to find a way to store the code to be used, which can technically be done with the NormalPlayerTask.Data
idea.
The code is stored in the first 4 bytes of NormalPlayerTask.Data
Thank you for the contribution, looks good to me!
(Updated #32)
added several solvers not introduced in other PRs
fixed issue where
Console.FindTask
could not return a taskfixed issue where
SimplifyPath
could fail when the path is empty