Skip to content
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.

Sign up for GitHub

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

Jump to bottom

More Inventory Mocking #1010

Open
3 of 11 tasks
fhnaumann opened this issue May 12, 2024 · 1 comment
Open
3 of 11 tasks

More Inventory Mocking #1010

fhnaumann opened this issue May 12, 2024 · 1 comment

Comments

@fhnaumann
Copy link
Contributor

fhnaumann commented May 12, 2024 •
edited
Loading

Is there an existing issue for this?

  • I have searched the existing issues

Describe the feature

In #981 I stumbled across some difficulties/inconsistencies using the inventory mocks. This feature request aims to solve these problems as well as to add mocking of new inventories (all in the style of #972).

Each inventory will have its own mock implementation and own simulation class (which receives a mocked instance). This class then has methods like simulatePlayerClickResult. These methods all reduce to a call to simulateInventoryClick in PlayerSimulation with appropriate parameters.
@Thorinwasher Should the simulation implementation be in the simulation class or mock class? You implemented it in the mock class, so I'm unsure what the purpose of the simulation classes are.

Below is a list of features. Mainly I will try to copy the behaviour of InventoryView#getSlotType. A useful overview for the different indicies in inventories is this resource.

  • Workbench
    • Differentiate between matrix and result index
  • Chest
  • Dispenser
  • Dropper
  • Furnace
    • Differentiate between input ("crafting"), fuel and result index
  • Enchanting
  • Brewing
    • Differentiate between fuel and ingredient

I will add more depending on the complexity. Right now I cannot guess how complicated everything will be and I will try to move one step at a time.
@Thorinwasher
Copy link
Contributor

Thorinwasher commented May 12, 2024 •
edited
Loading

Should the simulation implementation be in the simulation class or mock class? You implemented it in the mock class, so I'm unsure what the purpose of the simulation classes are.

It should be in the simulation class. I moved most of code over to the simulation classes, but in some cases it was too much work, so I put it up for later (Whenever / if the simulate method in the mock class get's removed)

To clarify: I think the thoughtprocess behind simulate classes was to lessen class bloat. The simulate methods that are left in their mock classes are only left so due to backwards compatibility.

@fhnaumann fhnaumann mentioned this issue May 12, 2024
Draft
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Thorinwasher @fhnaumann