Overview

The functions that the CLI module ultimately call given a user's command are contained within the actionmanagement.c module. At the time of this writing, there are 4 of these functions: do_item_action, do_path_action, do_item_item_action, and do_self_action.

do_item_action

This function handles actions that involve a single item. An example of this is eat bread. This function is called by CLI in the kind1_action_operation function in their operations.c file.

Parameters:

• chiventure_ctx_c *c is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.)
• action_type_t *a is the struct representing the action. This is assigned to the correct command string (i.e. "eat") by the CLI team, using a list containing all available actions. CLI gets this list from our get_supported_actions in our get_actions.c file
• item_t *i, the item that the user wants to act on. Again, this is set and passed in by CLI
• char **ret_string is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.

Basic Functionality

• Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
• This function then collapses multiple different commands into one blanket command (e.g. "use", "eat", etc. into "consume").
• If the action type is unsupported, assign ret_string to an error string
• Implement the actual effect by calling do_all_effects
• If there are other actions with a condition associated with this item action, remove the condition from all associated actions.
• Test if the player has won the game with this item. If so, set ret_string to the winning string

do_path_action

This function handles actions that involve a path. An example of this is go north. This function is called by CLI in the kind2_action_operation function in their operations.c file.

Parameters

• chiventure_ctx_c *c is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.)
• action_type_t *a is the struct representing the action. This is assigned to the correct command string (i.e. "go") by the CLI team, using a list containing all available actions. CLI gets this list from our get_supported_actions in our get_actions.c file
• path_t *i, the path that the user wants to take. Again, this is set and passed in by CLI
• char **ret_string is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.

Basic Functionality

• Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
• If the action type is unsupported, assign ret_string to an error string
• If valid path, move into the corresponding room by calling move_room
• If there are other actions with a condition associated with this path action, remove the condition from all associated actions.
• Test if the player is in the end/game-winning room. If so, set ret_string to the winning string

do_item_item_action

This function handles actions that involve a two items. An example of this is put chair table, meaning put chair on table. This function is called by CLI in the kind3_action_operation function in their operations.c file.

Parameters

• chiventure_ctx_c *c is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.)
• action_type_t *a is the struct representing the action. This is assigned to the correct command string (i.e. "put") by the CLI team, using a list containing all available actions. CLI gets this list from our get_supported_actions in our get_actions.c file
• item_t *direct, the first item that does the acting. Again, this is set and passed in by CLI
• item_t *indirect, the second item that receives the acting.
• char **ret_string is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.

Basic Functionality

• Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
• If the action type is unsupported, assign ret_string to an error string
• Implement a list of effects on the second item using a while loop
• If the effects are not successfully applied, assign ret_string to error message.
• If there are other actions with a condition associated with this item action, remove the condition from all associated actions.
• Test if the player has won the game with these items. If so, set ret_string to the winning string

do_self_action

This function handles actions that involve the player. An example of this is view stats. The structure of this function is different because no effects are being applied anywhere. Currently, this function only supports the view command on multiple things (stats, skills, quests, inventory, effects). This function is called by CLI in the kind4_action_operation function in their operations.c file.

Parameters

• chiventure_ctx_c *c is the chiventure struct variable that contains all the information available (i.e. game, player, objects from WDL, etc.)
• action_type_t *a is the struct representing the action. This is assigned to the correct command string (i.e. "view") by the CLI team, using a list containing all available actions. CLI gets this list from our get_supported_actions in our get_actions.c file
• char **target, an array of strings the user wants to act on. Currently, we support one or 2 strings (view quests or view quests "quest-id"). This is set and passed in by CLI after they parse user input
• char **ret_string is the pointer to a string that CLI passes in. In every single action function, we assign this pointer to the string we want to return. CLI then passes this string to the terminal.

Basic Functionality

• Lots of testing happens in this function. Asserts make sure that no parameter is NULL.
• If the action type is unsupported, assign ret_string to an error string
• The logic of this function is currently implemented as a nested if-elseif-else chain.
• We first test what the command is. We currently only support "view". Then, we check what the first string in target is.
• If the first string is "stats", we display the stats of the player by calling display_stats from game-state/player.h`
• If the first string is "effects", we display the stat effects from the player by calling display_stat_effects' from game-state/player.h`
• If the first string is "inventory", if the second string is NULL, we print the entire inventory using the display_inventory function in game-state/player.h. If the second string is not null, we pass this string in as the inventory item we want to view in more detail to display_inventory_item in game-state/player.h
• If the first string is "skills", if the second string is NULL, we print the entire skills list using the display_skills function in skilltrees/skilltree.h. If the second string is not null, we pass this string in as the skill we want to view in more detail to display_skill_description in skilltrees/skilltree.h
• If the first string is "quests", if the second string is NULL, we print the entire quest list using the show_quests function in quests/quests_cli.h. If the second string is not null, we pass this string in as the quest we want to view in more detail to show_task_tree in quests/quests_cli.h
• If the first string is "task", if the second string is NULL, we give an error string. This because "task" is only used if we want to view a specific task within a quest. Therefore, we need a task-id. If the second string is not null, we pass this string in as the task we want to view in more detail to show_task in quests/quests_cli.h