feat(elogin.lic): v2.0.0 for Lich 5.13+ yaml support

[OSXLich-Doug]

This proposal for a new elogin comes with some particulars. Please check 'other scripts' channel for details and helpful hints.

---

Important

elogin.lic updated to v2.0.0, adding Lich 5.13+ YAML support and refactoring for improved entry management and command handling.

• Behavior:
  • Adds support for Lich 5.13+ with YAML format in elogin.lic.
  • Refactors command usage to include ;elogin set realm, ;elogin add, ;elogin modify, ;elogin delete, and ;elogin list.
  • Updates login process to handle YAML and DAT formats.
• Functions:
  • Introduces load_entry_data, load_yaml_entries, load_dat_entries, save_entry_data for handling entry data.
  • Adds add_login_entry, modify_login_entry, delete_login_entry, list_login_entries for managing character entries.
  • Implements parse_arguments and show_usage for command parsing and help display.
• Misc:
  • Adds helper methods lich_version_at_least?, debug_log, handle_error, log_operation for version checking, logging, and error handling.
  • Updates resolve_login_helpers_paths and ensure_login_helpers_loaded for loading helper scripts.

^{This description was created by for c269a60. You can customize this summary. It will automatically update as commits are pushed.}

[OSXLich-Doug]

@ellipsis - close prior comments and review PR

[OSXLich-Doug]

@ellipsis - review commit

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to c269a60 in 2 minutes and 35 seconds. Click for details.

• Reviewed 690 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. scripts/elogin.lic:340

• Draft comment:
  The redundant argument removal (using args.shift) is not self-explanatory. Please add an inline comment explaining why this is needed and what specific Lich behavior it addresses.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. scripts/elogin.lic:479

• Draft comment:
  The instance_override computation uses _requested_game_code as a fallback. Ensure that char_entry always provides this field or add a fallback value to avoid potential nil issues.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% The comment is speculative - it says "Ensure that char_entry always provides this field" and suggests adding a fallback "to avoid potential nil issues." This is a classic "If X, then Y is an issue" type of comment. The rules explicitly state: "Do NOT make speculative comments, such as 'If X, then Y is an issue'. Only comment if it is definitely an issue." The comment doesn't provide evidence that _requested_game_code is actually nil in practice. It's asking the author to "ensure" something, which violates the rule about not asking authors to verify or ensure things. Without seeing the implementation of the helper methods, this appears to be a defensive programming suggestion rather than a definite bug. However, the comment could be correct if _requested_game_code is indeed sometimes nil. The helper method select_best_fit might not always set this field. If this is a real issue that would cause a runtime error, it should be kept. Even if _requested_game_code could be nil, the comment is phrased as "Ensure that..." which is explicitly against the rules. The comment doesn't demonstrate that this is definitely an issue - it's asking the author to ensure/verify. Without strong evidence that this causes a problem, and given the speculative phrasing, this should be deleted. This comment is speculative and uses "Ensure that..." phrasing, which violates the rules. Without strong evidence that _requested_game_code is actually nil in practice, this should be deleted.

3. scripts/elogin.lic:100

• Draft comment:
  The debug logging in load_yaml_entries assumes that the YAML structure includes an 'accounts' key. Consider adding a guard or clearer error handling if 'accounts' is missing.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a code quality suggestion for defensive programming in debug logging. While the suggestion is technically correct and would prevent a potential NoMethodError, there are several factors to consider: 1) This is debug-only code that most users won't run, 2) It's already wrapped in exception handling, 3) If the YAML structure is wrong, we'd want to know about it rather than silently logging 0, 4) The comment is about code that was added in the diff (new code), so it is about changes. However, this feels like a minor/nitpicky suggestion for debug code that's already error-handled. The rules say not to make comments that are "obvious or unimportant" and to only keep comments with "STRONG EVIDENCE" they are correct. The suggestion is technically valid and would make the code more defensive. Debug logging that crashes could be confusing even if caught by the outer rescue. The safe navigation operator is a Ruby best practice. This is actionable and clear. While technically valid, this is debug-only code already wrapped in exception handling. If the YAML structure is malformed (missing 'accounts'), the exception will be caught and logged with a clear error message on line 109. Making debug logging overly defensive could hide structural problems. This seems like an unimportant/minor suggestion that doesn't meet the "STRONG EVIDENCE" threshold for keeping. This is a minor code quality suggestion for debug logging that's already protected by exception handling. While not wrong, it doesn't meet the threshold of being clearly important enough to keep. The comment is about unimportant defensive programming in debug-only code.

4. scripts/elogin.lic:186

• Draft comment:
  When downloading login_helpers.rb in ensure_login_helpers_loaded, consider verifying the integrity or format of the downloaded file before writing and requiring it.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This comment is suggesting a security improvement - verifying the downloaded file before using it. However, according to the rules, I should only keep comments that identify clear issues requiring code changes. This is more of a "consider doing X" suggestion rather than "this code is wrong and needs to be fixed." The code does check for HTTP 200 status, which provides some validation. The comment uses "consider" which is a soft suggestion rather than identifying a definite problem. This falls under speculative comments that suggest improvements rather than fixing clear bugs. The comment could be arguing that downloading and executing code from a remote source without integrity checks is a legitimate security concern, not just a speculative improvement. This could be considered a real issue that should be addressed. While security is important, the comment uses "consider" language and suggests adding validation rather than pointing out that the current code is broken. The code already checks HTTP status. This is more of a code quality/security hardening suggestion rather than identifying a bug. The rules state not to make speculative comments and to only comment when there's clearly a code change required. This comment should be deleted. It's a speculative suggestion for improvement ("consider verifying") rather than identifying a clear bug or required code change. It falls under the category of code quality suggestions that aren't actionable as critical fixes.

Workflow ID: wflow_JXxgjQVvnFt6x4Wb

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}