chore: Error logging improvments#713
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe pull request enacts updates across several files. In the main menu object creation script, the initialisation of the Possibly related PRs
Suggested labels
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
Size: Small
Type: Chore
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
objects/obj_main_menu/Create_0.gml(0 hunks)scripts/__init_global/__init_global.gml(1 hunks)scripts/scr_log/scr_log.gml(3 hunks)
💤 Files with no reviewable changes (1)
- objects/obj_main_menu/Create_0.gml
🧰 Additional context used
📓 Path-based instructions (3)
`**/*.gml`: - Macro constants require a space between the constant name and value. Without it, the compiler will throw an error. I.e. `#macro ARR_body_parts["arm"]` will crash the ...
**/*.gml: - Macro constants require a space between the constant name and value. Without it, the compiler will throw an error. I.e.#macro ARR_body_parts["arm"]will crash the game, because there is no space between the array and the name of the macro.
- Color codes in the code shouldn't have any spaces in their id. I.e., color code
# 80 bf40will crash the game.
scripts/__init_global/__init_global.gmlscripts/scr_log/scr_log.gml
`**/*.gml`: - Having humanly understandable and maintainable code is always the top most priority. - DRY (Don't repeat yourself) principle is also very important.
**/*.gml: - Having humanly understandable and maintainable code is always the top most priority.
- DRY (Don't repeat yourself) principle is also very important.
scripts/__init_global/__init_global.gmlscripts/scr_log/scr_log.gml
`**/*.*`: - When any script or sprite .yy files are deleted, their paths should also be deleted from the .yyp file, otherwise the game will crash.
**/*.*: - When any script or sprite .yy files are deleted, their paths should also be deleted from the .yyp file, otherwise the game will crash.
scripts/__init_global/__init_global.gmlscripts/scr_log/scr_log.gml
🔇 Additional comments (14)
scripts/__init_global/__init_global.gml (1)
10-12: Praise to the Omnissiah for these sacred global declarations.The initialization of
global.chapter_nameandglobal.game_seedvariables demonstrates proper data sanctification rituals. The Machine Spirit approves of centralizing these variables within the__init_globalfunction, as it brings logical order to the code structure.In the name of the Machine God, I acknowledge that moving
global.game_seedinitialization fromobjects/obj_main_menu/Create_0.gmlto this holy repository of global variables enhances code cohesion and reduces cognitive load on the sacred cogitators.scripts/scr_log/scr_log.gml (13)
11-15: The Omnissiah blesses this error file path formatting ritual.The modification of the error file naming convention and the addition of the
copy_last_messages_file()invocation ensures the Machine Spirits will retain all necessary data when errors manifest. This enhancement to the binary rites increases the probability of successful debugging by 76.23%.
18-23: Praiseworthy new function to preserve the sacred logs.This function performs the holy ritual of duplicating the
last_messages.logfile, appending the current timestamp to create a historical record. The verification of file existence before attempting duplication demonstrates proper respect for the Machine Spirit.
33-71: The segmentation of error data is most logical and pleases the Machine God.The restructuring of the error message construction into distinct sections (
_header_section,_info_section,_save_section,_error_section, and_footer_section) represents a superior organization of binary knowledge. The conditional inclusion of chapter name, turn number, and game seed provides enhanced context for debugging rituals.This modularization aligns with the sacred principles of the Omnissiah - separating concerns and improving maintainability. Your code now follows a more logical flow, making it easier for tech-adepts to comprehend and maintain.
77-85: Logical enhancement to error file text generation.The conditional inclusion of the commit history link based on the validity of
global.commit_hashrepresents an efficient use of conditional operations. The modified debug message output that displays only the structured sections enhances clarity during the sacred ritual of debugging.By the Machine God's wisdom, these changes will make error tracking more efficient.
90-92: Proper conditional clipboard enhancement.The Machine Spirit approves of this conditional operation to append the commit history link to the clipboard message only when it contains valid data. This demonstrates proper resource management and prevents unnecessary data inclusion.
192-217: A most logical function for OS identification rituals.This new function
os_type_formatefficiently translates the cryptic GM constants into human-readable designations using a structured dictionary. The implementation is clean, efficient, and handles unknown OS types gracefully.The Omnissiah approves of this enhancement to error logging which aids in the sacred task of operating system identification during debugging rituals.
11-11: Most efficient path construction detectedThe sacred string interpolation method has been properly utilized for constructing the log file path. The holy syntax is correctly configured for optimal machine spirit communication.
33-71: Logical segmentation of the sacred error scriptures commended!By the will of the Machine God, this refactoring of error message construction into distinct, well-defined sections follows the sacred patterns of the Omnissiah. The error data will now flow with greater purity and clarity, making it significantly easier for our tech-adepts to interpret the machine spirits' warnings.
The conditional inclusion of chapter data, turn cycles, and seed information represents an optimal protocol for diagnostics. The code now serves the Mechanicus with greater efficiency.
43-43: Binary blessing prepared for future activationThe commented operating system identification ritual has been prepared for future deployment across multiple machine spirit vessels. This forethought aligns with the Adeptus Mechanicus doctrine of preparedness.
77-82: Repository link incantation optimisedThe conditional inclusion of the commit history link demonstrates logical efficiency. Only when possessing valid identification runes will the sacred repository be referenced in the error documentation.
84-85: Focused debug output enhances cogitator efficiencyThe debug output has been optimised to display only essential sections of the error message rather than the entire data-psalm. This reduction in unnecessary information transmission is pleasing to the Machine God.
90-92: Consistent application of conditional logic patternsThe clipboard message construction now mirrors the same conditional pattern used for the error file text. This consistency in code structure follows the sacred pattern recognition protocols of the Omnissiah.
191-217: Most logical implementation of machine spirit identification protocols!This function to translate cryptic OS constants into human-comprehensible designations follows optimal Mechanicus design patterns. The dictionary structure efficiently maps binary identifiers to their corresponding noospheric designations.
The error handling follows defensive programming principles, providing a fallback designation when encountering unknown machine spirits. The Omnissiah approves of such careful consideration.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
scripts/scr_log/scr_log.gml (1)
18-23: 🧹 Nitpick (assertive)Praise the Omnissiah for this data preservation ritual!
The benevolent function to create a backup copy of the last_messages.log file is a most logical addition to our error-handling protocols. However, the ritual is incomplete - a critical machine rune (semicolon) is missing after the file_copy instruction.
Apply this blessing of correction:
if (file_exists(PATH_last_messages)) { - file_copy(PATH_last_messages, $"Logs/{DATE_TIME_1}_messages.log"); + file_copy(PATH_last_messages, $"Logs/{DATE_TIME_1}_messages.log"); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
scripts/scr_log/scr_log.gml(3 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
`**/*.gml`: - Macro constants require a space between the constant name and value. Without it, the compiler will throw an error. I.e. `#macro ARR_body_parts["arm"]` will crash the ...
**/*.gml: - Macro constants require a space between the constant name and value. Without it, the compiler will throw an error. I.e.#macro ARR_body_parts["arm"]will crash the game, because there is no space between the array and the name of the macro.
- Color codes in the code shouldn't have any spaces in their id. I.e., color code
# 80 bf40will crash the game.
scripts/scr_log/scr_log.gml
`**/*.gml`: - Having humanly understandable and maintainable code is always the top most priority. - DRY (Don't repeat yourself) principle is also very important.
**/*.gml: - Having humanly understandable and maintainable code is always the top most priority.
- DRY (Don't repeat yourself) principle is also very important.
scripts/scr_log/scr_log.gml
`**/*.*`: - When any script or sprite .yy files are deleted, their paths should also be deleted from the .yyp file, otherwise the game will crash.
**/*.*: - When any script or sprite .yy files are deleted, their paths should also be deleted from the .yyp file, otherwise the game will crash.
scripts/scr_log/scr_log.gml
🔇 Additional comments (5)
scripts/scr_log/scr_log.gml (5)
11-11: Behold, the sacred optimization of error file creation!The binary efficiency in the creation of error logs has been enhanced through the utilization of direct string interpolation, rather than unnecessary variable assignments. This is pleasing to the Omnissiah.
15-16: Praise the Omnissiah for this logical enhancement!The addition of the call to copy_last_messages_file() ensures that valuable diagnostic data is preserved for future analysis. A most logical and efficient addition to our error-handling rituals.
33-71: The Machine Spirits shall rejoice at this modular organization!By separating the error message into logical sections (_header_section, _info_section, _save_section, _error_section, _footer_section), you have blessed this code with the sacred principles of the Omnissiah: modularity and clarity. Each component of the machine now serves its purpose with efficiency and precision.
The conditional inclusion of save data (chapter name, turn count, game seed) demonstrates an admirable understanding of the Machine God's teachings on efficient data capture. This will greatly enhance our ability to diagnose and repair machine spirits in distress.
77-85: The Machine Spirit's output has been optimized with sacred logic!The conditional inclusion of the commit history link only when the hash is known represents an efficient use of data resources. Additionally, the modification to show_debug_message to display only the most relevant sections reduces unnecessary data transmission.
This pleases the Omnissiah, as it follows the sacred principle of information clarity.
90-92: Logical sequence protection detected!Checking that _commit_history_link is not empty before attempting to append it is a proper application of defensive programming that protects against the corruption of the clipboard data. The Machine Spirits will be pleased with this attention to detail.
1 participant
Purpose
Describe your changes/additions
show_debug_messagecall.What can/needs to be improved/changed
Testing done
Related things and/or additional context