objectives todo.md

phase 1: discovery & documentation

• Variable; ObjectiveType
  • hwrm.lua
  • karos
• Variable; ObjectiveState
  • hwrm.lua
  • karos
• Dictionary; Objective
• Objective_Add
  • hwrm.lua
  • karos
• Objective_Addw
  • hwrm.lua
  • karos
• Objective_AddPresetID
  • hwrm.lua
  • karos
• Objective_AddDescription
  • hwrm.lua
  • karos
• Objective_AddDescriptionw
  • hwrm.lua
  • karos
• Objective_SetDescription
  • hwrm.lua
  • karos
• Objective_SetDescriptionw
  • hwrm.lua
  • karos
• Objective_GetState
  • hwrm.lua
  • karos
• Objective_SetState
  • hwrm.lua
  • karos
• Objective_Select
  • hwrm.lua
  • karos

phase 2: modkit api

this table can just be a memgroup, we'll override the set function to accept the options outlined

the objectives are stored as ObjectiveDef type, which is just a data table

however, the api calls :get and co. will return an Objective instead which is an api wrapper for those data objects (user shouldn'd need to interact with the data itself directly)

• modkit.objectives table
  • :set
    • ObjectiveSettings = { name: string, description?: string|nil, type?: ObjectiveType|nil, visible?: bool|nil, completed?: bool|nil }
  • :get
  • :delete
  • :find
• Objective class; we will hide the use of OS_ vars and just provide some toggle functions
  • :visible: (visible?: bool|nil) -> bool modkit objectives begin with state OS_Off, rather than OS_Incomplete
  • :description: (description?: string|UserData|nil) -> string accept UserData for wstrings
  • :completed: (completed?: bool|nil) -> bool setter / whether or not state is OS_Complete or not
  • :type: (type?: ObjectiveType|nil) -> ObjectiveType cant actually change an objectives type, will need to clone it and swap to the clone

aiming for something like

local o = modkit.objective:add("my-objective", {
	type = ObjectiveType.Primary,
	description = "Capture the point idk",
});

-- ...

o:visible(1);

-- ...

o:completed(1);

• by being a proxy, we gain the flexibility to fake a change in the objectives type which is not possible with the base api
• keep an eye out for data we should persist, i.e saving the description before setting/adding would let us provide a getter for it (which the API doesn't provide as usual)

phase 3 tests

write some unit tests and a feature test (i.e a 'demo' of the functions working well, output to console, run with a new 'test ' command probably

• tests for this feature
  • test files in modkit/test/
  • runnable from the console, i.e test objectives runs tests in data:scripts/modkit/tests/objectives.lua
  • Unit
    • get & set for all
    • flexible fn which can check an accessor or just a setter/getter
    • display test output in console
  • Feature
    • simple lifecycle & major functionality test with a handful of objectives
    • display output in console